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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document gives examples of signalling flows for the the IP multimedia call control based on SIP and SDP. 

These signalling flows demonstrate the interaction with the IP-connectivity network (GPRS), and with the protocol 
provided at the Cx interface. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.228 [2]. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] 3GPP TS 23.228: "IP multimedia subsystem; Stage 2". 
[3] IETF RFC 3261: "SIP: Session Initiation Protocol" 

[4] IETF RFC 2782: "A DNS RR for specifying the location of services (DNS SRV)". 

[5] IETF RFC 2806: "URLs for Telephone Calls". 

[6] IETF RFC 2916: "E.164 number and DNS". 

[7] 3GPP TS 33.203: "Access security for IP based services". 

[8] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2". 

[9] 3GPP TS 29.207: "End to end QuaHty of Service (QoS); stage 3". 

[10] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 

across the Gn and Gp Interface". 

[II] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx Interface; SignalHng flows and message 
contents". 

[12] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network Protocols; Stage 3". 

[13] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)". 

[14] IETF RFC 3263: "SIP: Locating SIP Servers" 

[15A] draft-ietf-dhc-dhcpv6-23 (February 2002): "Dynamic Host Configuration Protocol for IPv6 

(DHCPv6)" 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[15B] draft-ietf-sip-dhcpv6-00 (April 2002): "DHCPv6 options for SIP servers". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 
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[16] 
[17] 



3GPP TS 24.229: " IP Multimedia Call Control Protocol based on SIP and SDP; Stage3" 

IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted 
Identity within Trusted Networks" 



3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions 

IP multimedia session: set of multimedia senders and receivers and the data streams flowing from senders to receivers. 
IP multimedia sessions are supported by the IP multimedia CN Subsystem and are enabled by IP connectivity bearers 
(e.g. GPRS as a bearer). A user may invoke concurrent IP multimedia sessions. 

Stateful proxy: logical entity that maintains state information at least for the duration of a SIP transaction, see RFC 
3261 [3] 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BGCF Breakout Gateway Control Function 

CN Core Network 

COPS Common Open Policy Service 

CSCF Call Session Control Function 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

FQDN Fully-Qualified Domain Name 

G-MSC Gateway Mobile Switching Centre 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

HSS Home Subscriber Server 

I-CSCF Interrogating-CSCF 

IM IP Multimedia 

IP Internet Protocol 

IPv6 IP version 6 

MEGACO MEdia GAteway COntrol 

MGCF Media Gateway Control Function 

MGW Media Gateway 

P-CSCF Proxy-CSCF 

PDF Policy Decision Function 

PDP Packet Data Protocol 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

SBLP Service-based local policy 

S-CSCF Serving-CSCF 

SDP Session Description Protocol 

SGSN Serving GPRS Support Node 

SIP Session Initiation Protocol 

SS7 Signalling system no. 7 

UAC User Agent Client 

UAS User Agent Server 

UE User Equipment 

URI Uniform Resource Identifier 

UMTS Universal Mobile Telecommunications System 
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USIM User Service Identity Module 

4 Methodology 

4.1 Key required to interpret signalling flows 

4.1 .1 Key required to interpret signalling flow contents tables 

Contents tables are used to describe the contents of SIP methods. The following key (rules) have been applied to each 
contents table to improve readability, reduce errors and increase maintainability: 

a) Where a header field in the SIP method contents tables show only the header name, the contents are identical to 
the received request/response. The received request/response is identified as follows: 

where a request is generated as a result of a received request (as at a proxy), then the received request is that 
with the same method name and Cseq header; 

where a response is generated as a result of a received response (as at a proxy), then the received response is 
that with the same method name and Cseq header; 

where the response is generated as a result of a received request or response (as at a UA), then the received 
request is that with the same method name and Cseq header; 

where the request is generated as a result of a received response (as at a UA) then the received response is 
that immediately previously received. 

To enhance readability an indication of the received request/response is included in the method title, should the 
received request/response not be the immediate preceding request response. 

b) The (...) sequence of characters is used to indicate that the Content-Length field needs to be filled in, with the 
appropriate value i.e. the number of bytes in the payload. 

c) Repeated headers within a method are listed on a single line, with a comma used as delimiter. This convention is 
not mandatory but used in this specification for improved readability. 

d) Headers are listed within a table in the following order: 

1) hop by hop e.g. Via: 

2) end to end e.g. To: 

3) entity headers e.g. Content-Length: 

This convention is not mandatory but used in this specification for improved readability. 

4.1 .2 Key required to interpret signalling flow figures 

In order to differentiate between SIP methods and other protocol messages, the message name is preceded with the 
associated protocol for all non-SIP messages (e.g. GPRS: Activate PDP Context). 

4.1 .3 Functional entities covered in example flows 

The flows show the signalling exchanges between the following functional entities: 
User Equipment (UE); 

- Proxy-CSCF (P-CSCF); 

- Interrogating-CSCF (I-CSCF); 

- Serving-CSCF (S-CSCF); 
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- Media Gateway Control Function (MGCF); 

- Breakout Gateway Control Function (BGCF); 

- Home Subscriber Server (HSS). 

A number of the flows show a check against the filter criteria. A successful check against the filter criteria will involve 
the introduction of an application server into the path, operating in a number of different modes depending on the 
service provided. This could affect the example flows as follows: 

by the addition of extra URLs to a number of headers, e.g. Via, Record-Route, within the flow in which the 
evaluation of filter criteria occurs; 

by the addition of extra URLs to a number of headers, e.g. Via, Route in subsequent flows for the same dialog; 
and 

by the inclusion of functionality provided by the application server in this and subsequent flows. 

For simplicity, flows including the application server are not shown. For this reason there is no example of the 
functionality which is used for correlation of flows to and from the application server. 

For similar reasons, no functionality is shown for the Media Resource Function. 

4.2 Notation conventions 

4.2.1 Introduction 

This subclause details the notation conventions used in the present document. 

4.2.2 User Identities 

UE#l's public user identities are: 

userl_publicl @homel .net 

user 1 _public2 @home 1 . net 

etc. 
UE#l's private user identity is: 

userl_private@homel.net 
UE#2's public user identities are: 

user2_publicl @home2.net 

user2_public2 @home2.net 

etc. 
UE#2's private user identity is: 

user2_private @ home2.net 

4.2.3 Network Entities 

a) UE#l's associated entities: 
UE#l's home network is: 

homel.net 
The P-CSCF serving UE#1 in homel.net is: 
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pcscfl.homel.net 
The S-CSCF serving UE#1 is: 

scscfl.homel.net 
The I-CSCF in UE#rs home network (between proxy and serving CSCF) is: 

icscfl_p.homel.net 

If there are two I-CSCFs in homel.net involved in the call flows, then they are (from the left side of the 
individual call flow to its right side): 

icscfl_p.homel.net 

icscfl_s.homel.net 
NOTE 1: Typically, the second 1-CCSF will be between two S-CSCFs (hence use of "s"). 
UE#1 is roaming in: 

visitedl.net 
The P-CSCF serving UE#1 in visitedl.net is: 

pcscf 1 . visitedl .net 
The BGCF serving UE#1 is: 

bgcfl.homel.net 
The MGCF serving UE#1 is: 

mgcfl.homel.net 
b) UE#2's associated entities (where UE#2's home and/or visited network is different from that of UE#1): 
UE#2's home network is: 

home2.net 
The P-CSCF serving UE#2 in home2.net is: 

pcscf2.home2.net 
The S-CSCF serving UE#2 is: 

scscf2.home2.net 
The I-CSCF in UE#2's home network (between proxy and serving CSCF) is: 

icscf2_p.home2.net 

If there are two I-CSCFs in home2.net involved in the call flows, then they are (from the left side of the 
individual call flow to its right side): 

icscf2_s.homel.net 

icscf2_p.homel .net 
NOTE 2: Typically, the second I-CCSF will be between two S-CSCFs (hence use of "s"). 
UE#2 is roaming in: 

visited2.net 
The P-CSCF serving UE#2 in visited2.net is: 

pcscf2.visited2.net 
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The BGCF serving UE#1 is: 

bgcf2.home2.net 
The MGCF serving UE#1 is: 

mgcf2.home2.net 

c) UE#2's associated entities (where UE#2's home and/or visited network is the same as that of UE#1): 

UE#2's home network is: 

home 1 .net 
The P-CSCF serving UE#2 in homel.net is: 

pcscf2.homel.net 
The S-CSCF serving UE#2 is: 

scscf2.homel.net 
The I-CSCF in UE#2's home network (between proxy and serving CSCF) is: 

icscf2_p.homel .net 

If there are two UE#2 I-CSCFs involved in the call flows, then they are (from the left side of the individual call 
flow to its right side): 

icscf2_s.homel.net 

icscf2_p.homel.net 
NOTE 3: Typically, the second 1-CCSF will be between two S-CSCFs (hence use of "s"). 
UE#2 is roaming in: 

visitedl.net 
The P-CSCF serving UE#2 in visited2.net is: 

pcscf2.visitedl.net 
The BGCF serving UE#1 is: 

bgcf2.homel.net 
The MGCF serving UE#1 is: 

mgcf2.home 1 .net 

d) UE#3's (i.e. target in call transfer scenario) associated entities (where UE#3's home and/or visited network is 
different from that of UE#land UE#2): 

If there is a Call Transfer, then the Transfer Target is UE#3 

UE#3's home network is: 

home3.net 
The S-CSCF serving UE#3 is: 

scscf3.home3.net 
The I-CSCF in UE#3's home network (between proxy and serving CSCF) is: 

icscf3_p.home3.net 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 1 5 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

If there are two I-CSCFs in home3.net involved in the call flows, then they are (fi-om the left side of the 
individual call flow to its right side): 

icscf3_s.home3.net 

icscf3_p.home3.net 
NOTE 4: Typically, the second I-CCSF will be between two S-CSCFs (hence use of "s"). 
UE#3 is roaming in: 

visited3.net 
The P-CSCF serving UE#3 in visited3.net is: 

pcscD . visited3 .net 
The BGCF serving UE#1 is: 

bgcG.home3.net 
The MGCF serving UE#1 is: 

mgcf3.home3.net 



4.2.4 Configuration Iniding 



Where the I-CSCF(THIG) provides configuration hiding, some headers are tokenized. The encoding caused by this 
tokenization, and its reverse operation is not explicitly shown, but is indicated by preceding the tokenized string by 
"Token" and enclosing the tokenized string within parentheses. An example is: 

Via: SIP/2. 0/UDP icscfl_s.homel.net, 

SIP/2. 0/UDP Token (SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 

pcscf 1 .homel .net) Shomel .net; tokenized-by=homel . net, SIP/2 . 0/UDP [5555 : : aaa:bbb: ccc: ddd] 



4.3 Document Structure 

To improve readability, the document is structured at the highest level based on network configuration hiding. Each 
clause 'x' for the non-hiding scenario is mirrored for hiding, in a subsequent clause 'x+10'. 

For example: 

Clause 6: Signaling flows for REGISTER (non-hiding) Clause 16: Signalling flows for REGISTER (hiding) 

Clause 7: ...(non hiding) Clause 17: ...(hiding) 

etc. 

5 Elements of signalling flows for provision of IP- 

connectivity network 

Editor's note: The intent of this subclause is to provide set of subflows, that can be referred to from other flows, that 
show the creation of appropriate PDP contexts, and the maintenance and tearing down of those PDF 
contexts. 

Editor's note: The mechanism for communicating the CSCF address that the proxy forwards INVITEs to in the 200 
OK message is for further study. 

Editor's note: Input is required from SA3 on the authentication of the user and which network entity does this. 
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5.1 



Introduction 



Prior to communication with the IM CN subsystem, a successful GPRS attach procedure must be performed. Further a 
PDP context to be used for the SIP signalling must be established. This PDP context is established towards the GGSN 
in the H-PLMN or V-PLMN according to the APN and GGSN selection criteria described in 3GPP TS 23.060. The 
PDP context will provide the UE with an IPv6 address, which will serve as the host address for the duration of the PDP 
context. 

The PDP context where the SIP signalling is performed must be available as long as services from the IM CN 
subsystem are wanted. 

5.2 PDP context activation and P-CSCF discovery procedures 



5.2.1 



Introduction 



The Proxy-CSCF discovery shall be performed after GPRS attach and after or as part of a successful activation of a 
PDP context using one of the following mechanisms: 

Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [15 A], the DHCPv6 options for SIP servers 
[15B] and if needed DNS to obtain the P-CSCF address as described in subclause 5.2.2. 

Obtain the Proxy-CSCF address from the PDP Context Activation signalling as described in subclause 5. 2. 3. The 
UE can freely decide which of the described mechanisms it will use to acquire the P-CSCF address. In case 
several P-CSCF addresses are provided to the UE without sufficient priority indication, the selection of which 
P-CSCF address to use by the UE is implementation specific. 

5.2.2 DHCP procedure for P-CSCF discovery 

In DHCP procedures for P-CSCF discovery, the UE employs Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 
[15A], the DCHPv6 option for SIP servers [15B] and if needed DNS to obtain the P-CSCF address. 

Editor's Note: This approach needs further study on the interactions with the restrictions on the Signalling PDP 
Context, TS 23.228 subclause 4.2.6. 



UE 



GGSN 



PDP Context Activation Procedure 
< ► 




3. DNS -Query/Response 



DHCP server 



DNS server 



Figure 5.2.2-1 : P-CSCF discovery using DHCP and DNS 

1. PDP Context Establishment Procedure (UE to GPRS) 

Establishment of appropriate PDP context bearer by using the PDP Context Establishment procedure as 
specified in 3GPP TS 24.008. 

2. DHCP Query/Response (UE to DHCP) 

The UE sends a request to a DHCP server. It may requesta list of fully qualified domain names of P-CSCF(s) 
and the IP addresses of the DNS servers, or it may request a list of P-CSCF(s) IP address(es) as described in 
clause 4 of the DHCPv6 options for SIP servers [15B]. Multiple DHCP Query/Response message exchange 
may be required to retrieve the requested information. 
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3. DNS Query/Response (UE to DNS) 

If P-CSCF address(es) are not received in the DHCP Query /Response, and the transport protocol and port 
number are not known to UE, the UE performs a NAPTR query (for the domain returned in DHCP response) 
to select the transport protocol. Subsequently, the UE performs a SRV DNS query to retrieve a list of P- 
CSCF(s) IP addresses from which one is selected. If the response does not contain the IP addresses an 
additional AAAA DNS query is needed to resolve a Fully Qualified Domain Name (FQDN) to an IP 
address. 

Table 5.2.2-3a DNS: DNS Query (UE to DNS) 



OPCODE=SQUERY 

QNAME=pcscf .visitedl.net, QCLASS=IN, QTYPE=NAPTR 



The DNS records are retrieved according to RFC 3263 [14]. 

Table 5.2.2-3b DNS Query Response (DNS to UE) 



: OPCODE=SQUERY, RESPONSE, AA 






1 QNAME=pcscf .visitedl.net, QCLASS=IN, QTYPE 


=NAPTR 




1 pcscf.visitedl.net IN NAPTR 50 50 


's" "SIP+D2U" 


"" _sip._udp. pcscf.visitedl.net 


'■ IN NAPTR 90 5 


's" "SIP+D2T" 


"" _sip._tcp. pcscf.visitedl.net 


1 IN NAPTR 100 50 "s" 


'SIPS+D2T" 


_sips._tcp. pcscf.visitedl.net 



Based on the order and preference of the NAPTR record, and the local preference, UDP is preferred and the UE 
performs a DNS SRV lookup according to RFC 2782 [4]. 

Table 5.2.2-3c DNS: DNS Query (UE to DNS) 



OPCODE=SQUERY 

QNAME=_sip. _udp.pcscf.visitedl.net, QCLASS=IN, QTYPE=SRV 



The DNS records are retrieved according to RFC 2782 [4]. 

Table 5.2.2-3d DNS Query Response (DNS to UE) 



1 OPCODE=SQUERY, RESPONSE, AA 




; QNAME=_sip._udp.pcscf . visitedl . net. 


QCLASS=IN, QTYPE=SRV 


■ _sip._udp.pcscf.visitedl.net 


IN SRV 1 10 5060 pcscfl.visitedl.net 




IN SRV 1 5060 pcscf7.visitedl.net 


I pcscfl.visitedl.net 


IN AAAA 5555 :: aba: dab: aaa:daa 


I pcscf7.visitedl.net 


IN AAAA 5555: :ala:b2b:c3c:d4d 



In the Answer field of the query -response each P-CSCF is identified by its host domain name. The returned SRV 
Resource Records (RRs) are merged and ordered, and the selection technique (employing the Priority and Weight 
parameters returned in the RRs) as specified in RFC 2782 [4] is used to select the P-CSCF (i.e. the pcscfl.visitedl.net). 
Since the Additional Data field of the query-response also contains the IP address of the selected P-CSCF 
(i.e. 5555::aba:dab:aaa:daa), a new query to the DNS is not required. 

5.2.3 GPRS procedure for P-CSCF discovery 

GPRS procedures for P-CSCF discovery using the procedure specified in 3GPP TS 24.008 for establishment of an 
appropriate PDP context for IM subsystem signalling. The request for P-CSCF address(es) and the response P-CSCF 
address(es) are transparent to the SGSN. 
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UE 



SGSN 



1 Activate PDP Context Request 



5 Activate PDP Context Accept 



GGSN 



Create PDP Context Request 



3. Obtain IP addresses 
ofP-CSCF(s) 



Create PDP Context Response 

< 



Figure 5.2.3-1 : P-CSCF discovery using PDP Context Activation signalling 

1 . Activate PDP Context Request (UE to SGSN) 

UE requests establishment of a PDP context by using procedure as specified in 3GPP TS 24.008. The UE 
indicates that it requests a P-CSCF IP address(es). 

2. Create PDP Context Request (SGSN to GGSN) 

The SGSN selects a GGSN according to the APN selection criteria and forward the request to the GGSN. 

3. Obtain P-CSCF address(es) 

The GGSN obtains IP address(es) of P-CSCF(s) in the same network. 
NOTE: The mechanism to do this is a matter of internal configuration and is an implementation decision. 

4. Create PDP Context Response (GGSN to SGSN) 

The GGSN forwards the P-CSCF address(es) to the SGSN. 

5. Activate PDP Context Accept (SGSN to UE) 

The GGSN includes the IP address(es) of P-CSCF(s) in the response as specified in 3GPP TS 24.008. 

5.3 End-to-End QoS and signalling call flows interactions 

5.3.1 Mobile Originating with Service-based Local Policy, without resource 
reservation protocol, only GPRS procedures 

Figure 5.3.1-1 shows an example of the GPRS and the COPS interactions during a session setup when SBLP is being 
applied. Because the S-CSCF is not involved in GPRS interaction, it is not shown in the flow, but it is assumed that the 
S-CSCF or I-CSCF is the next entity in the signalling flow. 

This example is appropriate for a SIP session requesting the establishment of QoS preconditions, although only SBLP 
aspects are highlighted. It is assumed in this example that both the UAC and UAS have chosen to use the GPRS 
procedures to guarantee the QoS, which means both the UAC and UAS establish satisfactory PDP context on their 
respective accesses. It is assumed that the core network is DiffServ enabled and service based local policy (SBLP) 
decisions are taken by the PDF. The addition of the GPRS procedures in the access networks to the DiffServ enabled 
core network guarantees the end-to-end quality of service. 
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MO Network 



UE 



SGSN 



12. GPRS:Activate 
PDP context 



18. GPRS:Activate PDP 
context accept 



GGSN 



— 1. INVITE — 
-2. 100 Trying - 



7. 183 Session Progress - 
8. PRACK 



-11. 200 OK (PRACK) - 

13. GPRS: Create 

PDP context ^ 



17. GPRS: Create 
PDP response ^ 

— 19. UPDATE 



22. 200 OK (UPDATE) - 
24. 180 Ringing 

25. PRACK 



-28. 200 OK (PRACK)- 



-32. 200 OK (INVITE)- 
33. ACK 



P-CSCF (PDF) 



— 3. INVITE — 
-4. 100 Trying - 

5. 183 Session 
Progress 



6. Authorise OoS resources 



14. COPS: REO 
(Activate PDP context) ^ 

15. COPS: DEC 

(Policy information) 

16. COPS:RPT 

(Activate PDP context) ~ 



30. COPS: DEC 

(Open "gate") 

31. COPS: RPT 
(Report outcome)" 



9. PRACK ► 

hlO. 200 OK (PRACK) — 



20. UPDATE 1 

l21.200OK{UPDATE)- 

t — 23. 180 Ringing 



26. PRACK ► 

h27. 200 OK (PRACK) — 

1-29. 200 OK (INVITE) — 



-34. ACK- 



Figure 5.3.1-1 : Interaction between SIP/SDP, GPRS and COPS, Mobile originating side 

Only the relevant SIP, GPRS and COPS messages are mentioned in this subclause. The complete SIP messages are 
detailed in subclause 7.2.2. The GPRS messages are detailed in 3GPP TS 24.008 [12] and 3GPP TS 29.060 [10]. The 
COPS messages are detailed in 3GPP TS 29.207 [9]. 

6. Authorise QoS Resources 

At the reception of the 183 (Session Progress) response at the P-CSCF, the P-CSCF obtains the Media 
Authorisation Token from the PDF. 
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7. 183 (Session Progress) (P-CSCF to UE) 

This message typically contains the P-Media Authorization header, which holds the Media Authorisation 
Token. Upon receipt of the Media Authorisation Token, the UE generates a flow identifier which identifies 
an IP media flow associated with the SIP session. The Flow Identifiers are based on the sequence of media 
flows in the SDP. A Flow Identifier combined with the Authorization Token is sufficient to uniquely identify 
an IP media flow. 

12. GPRS: Active PDP Context (UE to SGSN) 

The UE sends an Activate PDP Context message to the SGSN as defined in 3GPP TS 24.008 [12]. The UE 
associates the PDP context to the session by including the media authorisation token information and the 
flow identifier(s) information. The PDP context is bi-directional. 

13. GPRS: Create PDP Context (SGSN to GGSN) 

The SGSN checks the user profile to authorise the requested QoS and also the available resource, if both are 
granted, it sends the corresponding Create PDP Context message to the GGSN as defined in 3GPP TS 29.060 
[10]. This message contains the media authorisation token information and the flow identifier(s) information. 

14. COPS: REQ (GGSN to PDF) 

When the Create PDP Context message is received in the GGSN containing the media authorisation token 
information and the flow identifier(s) information, the Policy Enforcement Point in the GGSN sends a COPS 
REQ message to the PDF as described in 3GPP TS 29.207 [9]. The PDF verifies that the media authorisation 
token information and the associated flow identifier(s) information are as expected. 

15. COPS: DEC (PDF to GGSN) 

The PDF sends a COPS DEC message back to the GGSN. 

16. COPS: RPT (GGSN to PDF) 

The GGSN sends a COPS RPT message back to the PDF, and includes an acknowledgement and/or an error 
response to the DEC message. 

17. GPRS: Create PDP Context Resp (GGSN to SGSN) 

The GGSN checks its own available resources and if enough resources are available, it sends a Create PDP 
Context Response message back to SGSN containing the negotiated value of the UMTS QoS IE as defined in 
3GPPTS 29.060 [10]. 

18. GPRS: Active PDP Context Accept (SGSN to UE) 

The SGSN sends an Activate PDP Context Accept message to UE containing the negotiated value of the 
UMTS QoS Information Element as defined in TS 24.008 [12]. 

19. UPDATE request (UE to P-CSCF) 

As the confirmation of the preconditions are requested in the 183 (Session Progress) response, when the UE 
finishes the QoS reservation for both the uplink and downlink direction, according to the GPRS procedures 
as indicated by the GPRS: Active PDP Context Accept message, it sends the UPDATE request to the 
terminating endpoint, via the signalling path established by the INVITE request. The UPDATE request 
includes in the SDP the information about the successful QoS bi-directional mode, due to the successful bi- 
directional PDP context established. The SDP indicates that the QoS resource reservation for both send and 
receive mode was successful from the terminating endpoint side. 

30. COPS: DEC (PDF to GGSN) 

When the P-CSCF receives the 200 (OK) response to the INVITE request, the PDF sends a COPS DEC 
message to the GGSN to enable the use of the authorised QoS resources, i.e. to open the 'gate', and allow 
packet flow in both directions in accordance with the policy decision within the GGSN Policy Enforcement 
Point. 

31. COPS: RPT (GGSN to PDF) 
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The GGSN receives the COPS DEC message and enables the use of the authorised QoS resources, i.e. opens 
the 'gate' within the GGSN, and sends a COPS RPT message back to the PDF. 

5.3.2 Mobile Termination, witin Service-based Local Policy, without 
resource reservation protocol, only GPRS procedures 

Figure 5.3.2-1 shows an example of the GPRS and the COPS interactions during a session setup when SBLP is being 
applied. Because the S-CSCF is not involved in GPRS interaction, it is not shown in the, but it is assumed that the S- 
CSCF is the next entity in the signalling flow. 

This example is appropriate for a SIP session requesting the establishment of QoS preconditions, although only SBLP 
aspects are highlighted. It is assumed in this example that both the UAC and UAS have chosen to use the GPRS 
procedures to guarantee the QoS, which means both the UAC and UAS establish satisfactory PDP context on their 
respective accesses. It is assumed that the core network is DiffServ enabled and service based local policy (SBLP) 
decisions are taken by the PDF. The addition of the GPRS procedures in the access networks to the DiffServ enabled 
core network guarantees the end-to-end quality of service. 
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Figure 5.3.2-1 Interaction between SIP/SDP, GPRS and COPS, Mobile terminating side 

Only the relevant SIP, GPRS and COPS messages are mentioned in this subclause. The complete SIP messages are 
detailed in subclause 7.4.2. The GPRS messages are detailed in 3GPP TS 24.008 [12] and 3GPP TS 29.060 [10]. The 
COPS messages are detailed in 3GPP TS 29.207 [9]. 

3. INVITE request (P-CSCF to UE) 

Upon receiving the INVITE request, the PDF generates the media authorisation token; the P-CSCF obtains 
the token from the PDF and puts it into the P-Media- Authorization header in the INVITE request and sends it 
to the UE. 
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5. 183 (Session Progress) (UE to P-CSCF) 

The UE sends the 183 (Session Progress) response back to P-CSCF with the accepted SDP. 

6. Authorise QoS Resources 

At the reception of the 183 (Session Progress) response at the P-CSCF, the P-CSCF authorizes the QoS 
resources needed for this session. 

9. PRACK (P-CSCF to UE) 

This PRACK request may carry the SDP which will be used for this session. The P-CSCF forwards the 
PRACK request to the UE. 

12. GPRS: Active PDP Context (UE to SGSN) 

The UE sends an Activate PDP Context message to the SGSN as defined in 3GPP TS 24.008 [12]. The UE 
associates the PDP context to the session by including the media authorisation token information and the 
flow identifier(s) information. The PDP Context is bi-directional. 

13. GPRS: Create PDP Context (SGSN to GGSN) 

The SGSN checks the user profile to authorise the requested QoS and also the available resources, if both are 
granted, it sends the corresponding Create PDP Context message to the GGSN as defined in 3GPP TS 29.060 
[10]. This message contains the media authorisation token information and the flow identifier(s) information. 

14. COPS: REQ (GGSN to PDF) 

When the Create PDP Context message is received in the GGSN containing the media authorisation token 
information and the flow identifier(s) information, the P olicy Enforcement Point in the GGSN sends a COPS 
REQ message to the PDF as described in 3GPP TS 29.207 [9]. The PDF verifies that the media authorisation 
token information and the associated flow identifier(s) information are as expected. 

15. COPS: DEC (PDF to GGSN) 

The PDF sends a COPS DEC message back to the GGSN. 

16. COPS: RPT (GGSN to PDF) 

The GGSN sends a COPS RPT message back to the PDF, and includes an acknowledgement and/or an error 
response to the DEC message. 

17. GPRS: Create PDP Context Response (GGSN to SGSN) 

The GGSN checks its own available resources and if enough resources are available, it sends a Create PDP 
Context Response message back to SGSN containing the negotiated value of the UMTS QoS Information 
Element as defined in 3GPP TS 29.060 [10]. 

18. GPRS: Active PDP Context Accept (SGSN to UE) 

The SGSN sends an Activate PDP Context Accept message to UE containing the negotiated value of the 
UMTS QoS Information Element as defined in 3GPP TS 24.008 [12]. 

23. 180 (Ringing) (UE to P-CSCF) 

As QoS preconditions are requested within the INVITE request, the UE waits for two events to occur. Firstly, 
the GPRS resource reservation must complete successfully as indicated by the GPRS: Active PDP Context 
Accept. Secondly, the resource reservation initiated by the originating endpoint must complete successfully. 
This is indicated by the SDP included in UPDATE request. The UE may now alert the subscriber of an 
incoming session attempt and send the 180 (Ringing) provisional response. 

30. COPS: DEC (PDF to GGSN) 

When the P-CSCF receives the 200 (OK) response to the INVITE request, the PDF shall send a COPS DEC 
message to the GGSN to enable the use of the authorised QoS resources, i.e., to open the 'gate', and allow 
packet flow in both directions in accordance with the policy decision within the GGSN PEP. 
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31. COPS: RPT (GGSN to PDF) 

The GGSN receives the COPS DEC message and enables the use of the authorised QoS resources, i.e., opens 
the 'gate' within the GGSN, and sends a COPS RPT message back to the PDF. 

5.3.3 Mobile originated sessions requesting tine establisinment of QoS 
preconditions and coordination witin GPRS bearer level 

Figure 5.3.3-1 shows an example of a SIP session requesting the establishment of QoS preconditions. Because the S- 
CSCF is not involved in the GPRS interaction, it is not shown in the flow, but it is assumed that the S-CSCF or 1-CSCF 
is the next entity in the signalling flow. 

It is assumed in this example that both the UAC and UAS have chosen to use the GPRS procedures to guarantee the 
QoS, which means both the UAC and UAS establish satisfactory PDP context on their respective accesses. It is further 
assumed that the core network is DiffServ enabled. The addition of the GPRS procedures in the access networks to the 
DiffServ enabled core network guarantees the end-to-end quality of service. 
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Figure 5.3.3-1 : Interaction between SIP/SDP and GPRS, mobile originating side 

Only the relevant SIP and GPRS messages are mentioned in this subclause. The complete SIP messages are detailed in 
subclause 7.2.2. The GPRS messages are detailed in 3GPP TS 24.008 [12] and 3GPP TS 29.060 [10]. 

1 . INVITE request (UE to P-CSCF) 

The UE (UAC - the session originator) sends the INVITE request, containing an initial SDP, to the P-CSCF. 
The SDP contains the set of codecs supported by the UE and includes the SDP extensions required to 
establish sessions with QoS preconditions. The UE also requests to establish QoS preconditions for all the 
media streams, but it does not request confirmation of the establishment of the QoS preconditions from the 
terminating side (UAS). 
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6. 183 (Session Progress) (P-CSCF to UE) 

The P-CSCF forwards the 183 (Session Progress) response from the UAS to the originating endpoint. The 
SDP contains the set of codecs supported by the UAS and includes the SDP extensions required to establish 
sessions with QoS preconditions. The UAS supports the QoS preconditions and requests that UAC sends a 
confirmation when the QoS preconditions are met. 

1 1. GPRS: Activate PDP Context (UE to SGSN) 

The UE sends an Activate PDP Context message to the SGSN with the UMTS QoS parameters. The PDP 
context is bidirectional. 

12. GPRS interaction 

The GPRS interaction procedures to create a PDP context are specified in 3GPP TS 29.060 [10]. 

13. GPRS: Activate PDP Context Accept (SGSN to UE) 

The SGSN sends an Activate PDP Context Accept message to the UE. 

14. UPDATE (UE to P-CSCF) 

When the UE finishes the QoS reservation for both the uplink and downlink direction, according to the GPRS 
procedures, it sends the UPDATE request to the terminating endpoint, via the signalling path established by 
the INVITE request. The UPDATE includes in the SDP the information about the successful QoS 
bidirectional mode, due to the successful bidirectional PDP context established. The request is sent first to the 
P-CSCF. 

25. 200 (OK) (P-CSCF to UE) 

The P-CSCF forwards the 200 (OK) final response to the session originator. The SDP contains an indication 
that the UE successfully reserved the QoS in the send and receive directions. 

5.3.4 Mobile Terminated sessions requesting tine establisinment of QoS 
preconcJitions and coordination witin GPRS bearer level 

Figure 5.3.4-1 shows an example of a SIP session requesting the establishment of QoS preconditions. Because the S- 
CSCF is not involved in the GPRS interaction, it is not shown in the flow, but it is assumed that the S-CSCF is the next 
entity in the signalling flow. 

It is assumed in this example that both the UAC and UAS have chosen to use the GPRS procedures to guarantee the 
QoS, which means both the UAC and UAS establish satisfactory PDP context on their respective accesses. It is further 
assumed that the core network is DiffServ enabled. The addition of the GPRS procedures in the access networks to the 
DiffServ enabled core network guarantees the end-to-end quality of service. 
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Figure 5.3.4-1 : Interaction between SIP/SDP and GPRS, mobile terminating side 

Only the relevant SIP and GPRS messages are mentioned in this subclause. The complete SIP messages are detailed in 
subclause 7.4.2. The GPRS messages are detailed in 3GPP TS 24.008 [12] and 3GPP TS 29.060 [10]. 

3. INVITE request (P-CSCF to UE) 

The P-CSCF forwards the INVITE request, containing an initial SDP, to the terminating UE (UAS). The 
SDP contains the set of codecs and includes the SDP extensions required to establish sessions with QoS 
preconditions. The UAC also requests to establish QoS preconditions for all the media streams, but it does 
not request confirmation of the establishment of the QoS preconditions from the terminating side (UAS). 
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5. 183 (Session Progress) (UE to P-CSCF) 

The UAS determines the complete set of codecs that it is capable and willing of supporting for this session. It 
determines the intersection with those appearing in the SDP in the INVITE request. The UAS responds with 
a 183 (Session Progress) response and sends this to the P-CSCF. The SDP contains the set of codecs 
supported by the UAS and includes the SDP extensions required to establish sessions with QoS 
preconditions. The UAS supports the QoS preconditions and requests that UAC sends a confirmation when 
the QoS preconditions are met. 

1 1. GPRS: Activate PDP Context (UE to SGSN) 

The UE sends an Activate PDP Context message to the SGSN with the UMTS QoS parameters. 

12. GPRS: interaction 

The GPRS interaction procedures to create a PDP context are specified in 3GPP TS 29.060 [10]. 

13. GPRS: Active PDP Context Accept (SGSN to UE) 

The SGSN sends an Activate PDP Context Accept message to the UE. 

15. UPDATE request (P-CSCF to UE) 

The P-CSCF forwards the UPDATE request to the UE. The UPDATE request includes in the SDP the 
information about the successful QoS bidirectional mode, due to the successful bidirectional PDP context 
established. 

18. 180 (Ringing) (UE to P-CSCF) 

Before proceeding with session establishment, the UE waits for two events. First, the GPRS resource 
reservation must complete successfully. Second, the resource reservation initiated by the originating endpoint 
must complete successfully (which is indicated by SDP included in the UPDATE request). The UE may now 
immediately accept the session (and proceed with step #24), or alert the destination subscriber of an 
incoming session attempt; if the latter it indicates this to the calling party by a 180 (Ringing) provisional 
response sent to the P-CSCF. 

24. 200 (OK) (UE to P-CSCF) 

When the called party answers, the terminating UE sends a 200 (OK) final response to the INVITE request to 
P-CSCF, and starts the media flow(s) for this session. The SDP contains an indication that the UE 
successfully reserved the QoS in the send and receive directions. 

5.3.5 P-CSCF Functionalities in End-to-End QoS and Signalling Mobile 
Originating Interactions with service-based local policy 
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Figure 5.3.5-1 : Interaction between P-CSCF and PDF, Mobile originating side 

6. PDF Generates Token and Authorise QoS Resource 

The Authorize QoS Resources procedure is triggered by the P-CSCF receiving a 183 (Session Progress) 
response. Based on the SDP information from INVITE and 183 (Session Progress) response, the PDF has 
sufficient information about this session, such as the end-points, bandwidth requirements, and the 
characteristics of the media exchange. 

The PDF shall authorize the required QoS resources for the session and install the IP bearer level policy 
based on information from the P-CSCF. In order to ensure that the IP bearer flow correlates to the one 
approved during the SIP session establishment, the SIP extensions for media authorization are used. 

Based on local policy, QoS resources may also be enabled at the time they are authorised by the PDF. 

The Authorization-Token is generated by the PDF and sent to the UE. 

7. 183 (Session Progress) (P-CSCF to UE) 

This message contains the P-Media- Authorization header, which holds the Media Authorisation Token. Upon 
receipt of the Media Authorisation Token, the UE generates a flow identifier which identifies an IP media 
flow associated with the SIP session. The Flow Identifiers are based on the sequence of media flows in the 
SDP. A Flow Identifier combined with the Authorization Token is sufficient to uniquely identify an IP 
media flow. 
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8. UMTS Bearer Setup 

The UE uses that token to activate PDP Context from GGSN network. The PDF makes final decision to 
enforce GGSN network to accept or reject PDP Context activation based service based local policy. 

10. Approval of QoS Commit 

The Approval of QoS Commit procedure is triggered by the P-CSCF receiving a 200 (OK) message. The 
PDF will interact with GGSN network to open the "gate" for the IP bearer. 

5.3.6 P-CSCF Functionalities in End-to-End QoS and Signalling Mobile 
Terminating Interactions with service-based local policy 
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Figure 5.3.6-1 : Interaction between P-CSCF and PDF, IVIobile terminating side 

3. Token Generation 

Based on the information got from the P-CSCF, the PDF generates an authorization token. Since PDF has not 
received all the information about end points yet, so QoS resource has not been authorized. 
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4. INVITE request (P-CSCF to UE) 

The INVITE request contains the P-Media- Authorization header, which holds the Media Authorisation 
Token. 

7. QoS Authorization 

The Authorize QoS Resources procedure is triggered by the P-CSCF receiving a 183 (Session Progress) 
response. Based on the SDP information from INVITE request and 183 (Session Progress) response, the PDF 
has sufficient information about this session, such as the end-points, bandwidth requirements, and the 
characteristics of the media exchange. 

The PDF authorizes the required QoS resources for the session and installs the IP bearer level policy based 
on information from the P-CSCF. In order to ensure that the IP bearer flow correlates to the one approved 
during the SIP session establishment, the SIP extensions for media authorization are used. 

Based on local policy, QoS resources may also be enabled at the time they are authorised by the PDF. 

8. 183 (Session Progress) (P-CSCF to UE) 

Upon receipt of this message, the UE generates a flow identifier which identifies an IP media flow associated 
with the SIP session. The Flow Identifiers are based on the sequence of media flows in the SDP. A Flow 
Identifier combined with the Authorization Token are sufficient to uniquely identify an IP media flow. 

9. UMTS Bearer Setup 

UE uses that token to activate PDP Context from GGSN network. The PDF makes final decision to enforce 
GGSN network to accept or reject PDP Context activation based service based local policy. 

1 1 . Approval of QoS Commit 

The Approval of QoS Commit procedure is triggered by the P-CSCF receiving a 200 (OK) response. The 
PDF will interact with GGSN network to open the "gate" for the IP bearer. 



6 Signalling flows for REGISTER (non hiding) 

6.1 Introduction 

In IMS Authentication is performed at registration time. The following sections show examples of SIP registration and 
UMTS AKA authentication. It is possible for the home to require other types of authentication. 

In the example below. Digest AKA is used within SIP headers to carry the information related to the authentication- 
challenge and response. 

6.2 Registration signalling: user not registered 

Figure 6.2-1 shows the registration signalling flow for the scenario when the user is not registered. For the purpose of 
this registration signalling flow, the subscriber is considered to be roaming. This flow also shows the authentication of 
the private user identity. In this signalling flow, the home network does not have network configuration hiding active. 
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Figure 6.2-1 : Registration signalling: user not registered 

1 . GPRS Attach / PDP Context Establishment and P-CSCF Discovery (UE to GPRS) 

This signalling flow is shown to indicate prerequisites for the registration signalling. 
See subclause 5.2 for details. 
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2. REGISTER request (UE to P-CSCF) - see example in table 6.2-2 

The purpose of this request is to register the user's SIP URI with a S-CSCF in the home network. This request 
is routed to the P-CSCF because it is the only SIP server known to the UE. In the following SIP request, the 
Contact field contains the user's host address. 

The P-CSCF will perform two actions, binding and forwarding. The binding is between the User's SIP 
address (userl_publicl@homel.net) and the host (terminal) address ([5555::aaa:bbb:ccc:ddd]) which was 
acquired during PDP context activation process. 



Table 6.2-2: REGISTER request (UE to P-CSCF) 



REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

From; <sip ; userl_publicl@homel .net>;tag=4fa3 

To ; <sip ; userl_publicl@homel . net> 

Contact; sip; [5555; ; aaa; bbb; ccc ; ddd] 

Call- ID; apb03a0s0 9dkjdfglkj4 9111 

Authorization; Digest username="userl_private@homel . net " , realm="registrar . homel . net " , nonce=""^ 

uri="sip; registrar. homel .net", response="" 

Security-Client; ipsec-3gpp; alg=hmac-sha-l-96; spi=12345678; portl=1357 

Require; sec-agree 

CSeq; 1 REGISTER 

Supported; path 

Expires; 7200 

Content-Length; 

Request-URI: The Request-URI (the URI that follows the method name, "REGISTER", in the first line) indicates 
the destination domain of this REGISTER request. The rules for routing a SIP request describe 
how to use DNS to resolve this domain name ("registrar.homel.net") into an address or entry point 
into the home operator's network (the I-CSCF). This information is stored in the USIM. 

Via: IPv6 address of the SIP session allocated during the PDP Context Activation process. 

Max-Forwards: Set to 70 by the UE and used to prevent loops. 

From: This indicates the public user identity originating the REGISTER request. The public user identity 

may be obtained from the USIM. 

To: This indicates the public user identity being registered. This is the identity by which other parties 

know this subscriber. It may be obtained from the USIM. 

Contact: This indicates the point-of-presence for the subscriber - the IP address of the UE. This is the 

temporary point of contact for the subscriber that is being registered. Subsequent requests destined 
for this subscriber will be sent to this address. This information is stored in the P-CSCF and S- 
CSCF. 

Authorization: It carries authentication information. The private user identity (userl_private@homel.net) is 

carried in theusername field of the Digest AKA protocol. The uri parameter (directive) contains 
the same value as the Request-URI. The realm parameter (directive) contains the network name 
where the username is authenticated. The Request-URI and the realm parameter (directive) value 
are obtained from the same field in the USIM and therefore, are identical. In this example, it is 
assumed that a new UICC card was just inserted into the terminal, and there is no other cached 
information to send. Therefore, nonce and response parameters (directives) are empty. 

Security-Client: lists the supported algorithm(s) by the UE. 

Supported: This header is included to indicate to the recipient that the UE supports the Path header. 

Upon receiving this request the P-CSCF will set it's SIP registration timer for this UE to the Expires time in 
this request. 
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3. DNS:DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
the DNS queries to locate the I-CSCF in the home network. The look up in the DNS is based on the address 
specified in the Request URI. 

The P-CSCF sends the REGISTER request - after local processing - to the address indicated in the Request- 
URI. When forwarding the REGISTER request the P-CSCF needs to specify the protocol, port number and 
IP address of the I-CSCF server in the home network to which to send the REGISTER request. The P-CSCF 
tries to find this information by querying the DNS. Since the Request-URI does not specify a numeric IP 
address, and the transport protocol and port number are not indicated, the P-CSCF performs an NAPTR 
query for the domain specified in the Request-URI. 

Table 6.2-3a DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME=registrar. homel.net, QCLASS=IN, QTYPE=NAPTR 



The DNS records are retrieved according to RFC 3263 [14]. 

Table 6.2-3b DNS Query Response (DNS to P-CSCF) 
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Based on the order and preference of the NAPTR record and the local preference, UDP is preferred and the 
P-CSCF finds the I-CSCF by a DNS SRV lookup according to RFC 2782 [4]. 

Table 6.2-3c: DNS: DNS Query (P-CSCF to DNS) 

OPCODE=SQUERY 

QNAME=_sip. _udp.registrar.homel.net, QCLASS=IN, QTYPE=SRV 

The DNS records are retrieved according to RFC 2782 [4]. 

Table 6.2-3d: DNS Query Response (DNS to P-CSCF) 



OPCODE=SQUERY, RESPONSE, AA 
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net. 


QCLASS=IN, QTYPE= 


= SRV 




_sip ._udp . registrar . homel . net 
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IN AAAA 5555 
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IN AAAA 5555 


: ala 


b2b:c3c:d4d 



In the Answer field of the query-response each I-CSCF is identified by its host domain name. The returned 
SRV Resource Records (RRs) are merged and ordered, and the selection technique (employing the Priority 
and Weight parameters returned in the RRs) as specified in RFC 2782 [4] is used to select the I-CSCF 
(i.e. the icscfl_p.homel.net). Since the Additional Data field of the query -response also contains the IP 
address of the selected I-CSCF (i.e. 5555::aba:dab:aaa:daa), a new query to the DNS is not required. 

Once the IP address of the I-CSCF is obtained, the P-CSCF forwards the REGISTER request to this IP 
address (i.e. 5555::aba:dab:aaa:daa) using the UDP protocol and port number 5060. 

4. REGISTER request (P-CSCF to I-CSCF) - see example in table 6.2-4 
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The P-CSCF needs to be in the path for all mobile originated and mobile terminated requests for this user. To 
ensure this, the P-CSCF adds itself to the Path header value for future requests. 

The P-CSCF binds the public user identity under registration to the Contact header supplied by the user. 

The P-CSCF adds also the P- Visited-Network-ID header with the contents of the identifier of the P-CSCF 
network. This may be the visited network domain name or any other identifier that identifies the visited 
network at the home network. 

This signalling flow shows the REGISTER request being forward from the P-CSCF to the I-CSCF in the 
home domain. 

P-CSCF removes the Security-Client and Require: sec-agree headers prior to forwarding the message. 
Table 6.2-4: REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] ;branch=z9hG4bKnashds7 
Max-Forwards; 69 

Path; <sip;pcscfl. visitedl. net; lr> 
Require; path 

P-Visited-Network-ID ; "Visited Network Number 1" 

P-Charging-Vector ; icid-value=a834bcl92f e3; icid-generated-at= [5555 ; ; e9e ; d8d; c7c ;b6b] 
From; 
To; 

Contact ; 
Call-ID; 

Authorization; Digest username = "userl_private@homel . net " , realm="registrar . homel . net " , nonce = "", 
uri="sip; registrar. homel .net", response="", integrity-protected="no" 
CSeq; 

Supported; 
Expires ; 
Content-Length ; 

Path: This is the address of the P-CSCF and is included to inform the S-CSCF where to route 

terminating sessions. 

Require: This header is included to ensure that the recipient correctly handles the Path header. If the 

recipient does not support the path header, a response will be received with a status code of 420 
and an Unsupported header indicating "path". Such a response indicates a misconfiguration of the 
routing tables and the request has been routed outside the IM CN subsystem. 

P- Visited-Network-ID: It contains the identifier of the P-CSCF network at the home network. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

5. Cx: User registration status query procedure 

The I-CSCF makes a request for information related to the Subscriber registration status by sending the 
private user identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF 
required capabilities and the I-CSCF uses this information to select a suitable S-CSCF. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-5a provides the parameters in the REGISTER request (flow 4) which are sent to the HSS. 
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Table 6.2-5a Cx: User registration status query procedure (l-CSCF to HSS) 



IVIessage 

source & 

destination 


Cx Information 
element name 


Information 
Source in 
REGISTER 


Description 


l-CSCF to HSS 


Private User 
Identity 


Authorization: 


The Private User Identity is 
encoded in the username 
field according to the 
Authorization protocol. 


Public User 
Identity 


To: 


Identity which is used to 
communicate with other 
users 


Visited Network 
Identifier 


P-Visited- 
Network-ID: 


This information indicates 
the network identifier of the 
visited network 



6. REGISTER request (I-CSCF to S-CSCF) - see example in table 6.2-6 

I-CSCF does not modify the Path header. 

This signalhng flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. 

Table 6.2-6: REGISTER request (l-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK2 4 0f 34 .1, SIP/2 .0/UDP 
[ 5555 : : aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 68 
Path: 
Require : 

P-Visited-Network-ID : 
P-Charging-Vector : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
CSeq: 

Supported: 
Expires : 
Content-Length : 

Path: The S-CSCF stores the contents of the Path header and uses the URI for routing mobile terminated 

sessions. 

Upon receiving this request the S-CSCF may set its SIP registration timer for this UE to the Expires time in 
this request or the S-CSCF may assign another registration timer for this registration 

7. Cx: Authentication procedure 

As the REGISTER request arrived without integrity protection to the P-CSCF, the S-CSCF shall challenge it. 
For this, the S-CSCF requires at least one authentication vector to be used in the challenge to the user. If a 
valid AV is not available, then the S-CSCF requests at least one AV from the HSS. 

The S-CSCF indicates to the HSS that it has been assigned to serve this user. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-7a provides the parameters in the REGISTER request (flow 6) which are sent to the HSS. 
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Table 6.2-7a Cx: S-CSCF authentication information procedure (S-CSCF to HSS) 



IVIessage 

source & 

destination 


Cx Information 
element name 


Information 
Source in 
REGISTER 


Description 


S-CSCF to HSS 


Public User 
Identify 


To: 


Identity which is used to 
communicate with other 
users 


Private User 
Identity 


Authorization: 


The Private User Identity is 
encoded in the username 
field according to the 
Authorization protocol. 


S-CSCF Name 


Request-URI: 


This information element 
contains the name of the S- 
CSCF. The presence of this 
IE indicates that the user has 
not been authenticated yet 
by the S-CSCF 



8. Authentication vector selection 

The S-CSCF selects an authentication vector for use in the authentication challenge. For detailed description 
of the authentication vector, see 3GPP TS 33.203. 

NOTE 1 : The authentication vector may be of the form as in 3GPP TS 33.203 (if IMS AKA is the selected 
authentication scheme): 

- AV = RANDnllAUTNJIXRES„IICKnllIK„ where: 

RAND: random number used to generate the XRES, CK, IK, and part of the AUTN. It is also used 
to generate the RES at the UE. 

- AUTN: Authentication token (including MAC and SQN). 

XRES: Expected (correct) result from the UE. 

CK: Cipher key (optional). 

IK: Integrity key. 

9. 401 Unauthorized response (S-CSCF to I-CSCF) - see example in table 6.2-9 

The authentication challenge is sent in the 401 Unauthorized response towards the UE. 

Table 6.2-9: 401 Unauthiorized response (S-CSCF to I-CSCF) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From; <sip ; userl_publicl@homel .net>;tag=4fa3 
To; <sip ; userl_publicl@homel . net>; tag=5ef4 
Call- ID; apb03a0s0 9dkjdfglkj4 9111 

www-Authenticate; Digest realm="registrar .homel . net ", nonce=base64 (RAND + AUTN + server specific 
data) , algorithm=AKAvl-MD5, ik="00112233445566778899aabbccddeef f ", 
ck="ffeeddccbbaal 122334455 6677 8 8 9900" 
CSeq; 1 REGISTER 
Content-Length; 

WWW-Authenticate: The S-CSCF challenges the user. The nonce includes the quoted string, base64 encoded value 
of the concatenation of the AKA RAND, AKA AUTN and server specific data. The S-CSCF 
appends also the Integrity Key (IK) and the Cyphering key (CK). 

NOTE 2: The actual nonce value in the WWW-Authenticate header field is encoded in base64, and it may look 
like:nonce="A34CmH-Fva37UYWpGNB34JP" 

10. 401 Unauthorized response (I-CSCF to P-CSCF) - see example in table 6.2-10 
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The authentication challenge is sent in the 401 Unauthorized response towards the UE. 
Table 6.2-10: 401 Unauthorized response (l-CSCF to P-CSCF) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 

www-Authenticate : 
CSeq: 
Content-Length : 

1 1. 401 Unauthorized response (P-CSCF to UE) - see example in table 6.2-11 

The P-CSCF removes any keys received in the 401 Unauthorized response and forwards the rest of the 
response to the UE. 

Table 6.2-11 : 401 Unauthorized response (P-CSCF to UE) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

www-Authenticate: Digest realm="registrar . homel . net " , nonce=base64 (RAND + AUTN + server specific 

data) , algorithm=AKAvl-MD5 

Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

CSeq: 

Content-Length : 

WWW-Authenticate: The P-CSCF removes the ik and ck parameters (directives) from the header. 

Security-Server: q is the preference value, 0. 1 means IPsec is the first preferred choice. The q value represents 
only relative degradation of all mechanisms listed here. The lower value, the higher prority. 

12. Generation of response and session keys at UE 

Upon receiving the Unauthorised response, the UE extracts the MAC and the SQN from the AUTN. The UE 
calculates the XMAC and checks that XMAC matches the received MAC and that the SQN is in the correct 
range. If both these checks are successful the UE calculates the response, RES, and also computes the session 
keys IK and CK. The RES is put into the Authorization header and sent back to the registrar in the 
REGISTER request. 

13. REGISTER request (UE to P-CSCF) - see example in table 6.2-13 

Table 6.2-13 REGISTER request (UE to P-CSCF) 

REGISTER sip:registrar. homel. net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel .net>;tag=4fa3 

To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] > 

Call- ID: apb03a0s0 9dltjdfgl]ij4 9111 

Authorization: Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 

nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 

uri="sip: registrar. homel .net", response="662 9fae4 93 93a053 97450 97 8507c4efl" 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

CSeq: 2 REGISTER 

Supported: path 

Expires: 7200 

Content-Length: 

Authorization: This carries the response to the authentication challenge received in step 1 1 along with the private 
user identity, the realm, the nonce, the URI and the algorithm. 
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This message is protected by the IPsec S A negotiated. 

14. DNS: DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
the DNS queries to locate the 1-CSCF in the home network. The look up in the DNS is based on the domain 
name specified in the Request URI. 

The P-CSCF sends the REGISTER request - after local processing - to the address indicated in the Request- 
URI. When forwarding the REGISTER request the P-CSCF needs to specify the protocol, port number and 
IP address of the 1-CSCF server in the home network to which to send the REGISTER request. The P-CSCF 
tries to find this information by querying the DNS. Since the Request-URJ does not specify a numeric IP 
address, and the transport protocol and port number are not indicated, the P-CSCF performs an NAPTR 
query for the domain specified in the Request-URL 

Table 6.2-1 4a DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME=registrar. homel.net, QCLASS=IN, QTYPE=NAPTR 



The DNS records are retrieved according to RFC 3263 [14]. 

Table 6.2-1 4b DNS Query Response (DNS to P-CSCF) 



: OPCODE=SQUERY, RESPONSE, AA 

: QNAME=registrar. homel.net, QCLASS=IN, QTYPE=NAPTR 

■ 

: registrar.homel.net IN NAPTR 50 50 "s" "SIP+D2U" "" _sip._udp.registrar.homel.net 

1 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.registrar.homel.net 

: IN NAPTR 100 50 "s" "SIPS+D2T" "" _sips._tcp.registrar.homel.net 



Based on the order and preference of the NAPTR record and the local preference, UDP is preferred and the 
P-CSCF finds the 1-CSCF by an DNS SRV lookup according to RFC 2782 [4]. 

Table 6.2-1 4c DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME= sip._udp.registrar.homel.net, QCLASS=IN, QTYPE=SRV 



The DNS records are retrieved according to RFC 2782 [4]. 

Table 6.2-1 4d DNS Query Response (DNS to P-CSCF) 



i OPCODE=SQUERY, RESPONSE, AA 

'• QNAME= sip. _udp. registrar .homel 


net. 


QCLASS=IN, 


QTYPE=SRV 




I _sip._udp.registrar.homel.net 




IN SRV 
IN SRV 


1 10 5060 
1 5060 


icscfl_p. homel . net 
icscf7_p. homel . net 


I icscfl_p.homel.net 
j icscf7_p.homel.net 






IN AAAA 
IN AAAA 


5555: :aba 
5555: :ala 


dab: aaa: daa 
b2b:c3c:d4d 



In the Answer field of the query-response each I-CSCF is identified by its host domain name. The returned 
SRV Resource Records (RRs) are merged and ordered, and the selection technique (employing the Priority 
and Weight parameters returned in the RRs) as specified in RFC2782 [4] is used to select the I-CSCF (i.e. the 
icscfl_p.homel.net). Since the Additional Data field of the query-response also contains the IP address of the 
selected 1-CSCF (i.e. 5555::aba:dab:aaa:daa), a new query to the DNS is not required. 

Once the IP address of the I-CSCF is obtained, the P-CSCF forwards the REGISTER request to this IP 
address (i.e. 5555::aba:dab:aaa:daa) using the UDP protocol and port number 5060. 

15. REGISTER request (P-CSCF to I-CSCF) - see example in table 6.2-15 
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This signalling flow shows the REGISTER request being forwarded from the P-CSCF to the I-CSCF in the 
home domain. 

Table 6.2-15 REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Path: <sip:pcscfl. visitedl. net; lr> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P-Charging-Vector : icid-value=a834bcl92fe3; icid-generated-at= [5555 : : e9e : d8d: c7c:b6b] 
From: 
To: 

Contact : 
Call-ID: 

Authorization: Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5, 

uri="sip: registrar. homel .net", response="662 9fae4 93 93a053 9745 97 85 07c4efl", integrity- 
protected="yes" 
CSeq: 

Supported: 
Expires : 
Content-Length : 



Path: 



This is the P-CSCF URI and it is included to inform the S-CSCF where to route terminating 
sessions. 



16. Cx: User registration status query procedure 

The I-CSCF requests information related to the Subscriber registration status by sending the private user 
identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF name which 
was previously selected in step 5 (Cx: User registration status query procedure). 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-16a provides the parameters in the REGISTER request (flow 15), which are sent to the HSS. 

Table 6.2-16a Cx: User registration status query procedure (I-CSCF to HSS) 



IVIessage 

source & 

destination 


Cx Information 
element name 


Information 
Source in 
REGISTER 


Description 


I-CSCF to HSS 


Private User 
Identity 


Authorization: 


The Private User Identity is 
encoded in the username 
field according to the 
Authorization protocol. 


Public User 
Identity 


To: 


Identity which is used to 
communicate with other 
users 


Visited Network 
Identifier 


P-Visited- 
Network-ID: 


This information indicates 
the network identifier of the 
visited network 



17. REGISTER request (I-CSCF to S-CSCF) - see example in table 6.2-17 

This signalling flow forwards the REGISTER request from the I-CSCF to the S-CSCF. 

Table 6.2-17: REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel. net SIP/2.0 

via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK2 4 0f 34 .1, SIP/ 2 .0/UDP 
[ 5555 : : aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 68 
Path: 
Require : 
P-Visited-Network-ID : 
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P-Charging-Vector : 

From; 

To: 

Contact : 

Call-ID: 

Authorization : 

CSeq: 

Supported: 

Expires : 

Content-Length : 



Path: 



The S-CSCF stores the contents of the Path header and uses this URI for routing mobile 
terminated sessions. 

P-Charging- Vector: The S-CSCF stores the contents of the icid parameters for possible charging activities. 

18. Authentication 

Upon receiving an integrity protected REGISTER request carrying the authentication response, RES, the S- 
CSCF checks that the user's active, XRES matches the received RES. If the check is successful then the user 
has been authenticated and the public user identity is registered in the S-CSCF. 

19. Cx: S-CSCF registration notiflcation procedure 

On registering a user the S-CSCF informs the HSS that the user has been registered at this instance. Upon 
being requested by the S-CSCF , the HSS will also include the user profile in the response sent to the S- 
CSCF. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-19a provides the parameters in the REGISTER request (flow 17), which are sent to the HSS. 

Table 6.2-1 9a Cx: S-CSCF registration notification procedure (S-CSCF to HSS) 



Message 

source & 

destination 


Cx Information 
element name 


Information 
Source in 
REGISTER 


Description 


S-CSCF to HSS 


Public User 
Identify 


To: 


Identity which is used to 
communicate with other 
users 


Private User 
Identity 


Authorization: 


The Private User Identity is 
encoded in the username 
field according to the 
Authorization protocol. 


S-CSCF name 


Request-URI: 


This information indicates 
the serving CSCF's name of 
that user 



20. 200 OK response (S-CSCF to I-CSCF) - see example in table 6.2-20 

The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful. 

Table 6.2-20: 200 OK response (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK2 4 0f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa :bbb : ccc :ddd] ;branch=z9hG4bKnashds7 
Path: <sip:pcscfl. visitedl. net; lr> 
Service-Route : <sip:scscfl. homel . net ; lr> 
From: 
To: 

Call-ID: 

Contact : <sip: [5555 : : aaa:bbb: ccc : ddd] >;expires=7200 
CSeq: 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel .net>, <sip: userl_public3@homel .net>, <sip: +1-2 12-555- 
llll@homel .net; user=phone> 
Content-Length : 
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Service-Route: The S-CSCF inserts the Service-Route header value that includes the own S-CSCF URI. 
21. 200 OK response (I-CSCF to P-CSCF) - see example in table 6.2-21 

The I-CSCF forwards the 200 (OK) response from the S-CSCF to the P-CSCF indicating that Registration 

was successful. 

Table 6.2-21 : 200 OK response (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] ;branch=z9hG4bKnashds7 
Path: 

Service-Route : 
From: 
To: 

Call-ID: 
Contact : 
CSeq: 
Date: 

P-Associated-URI : 
Content-Length : 

22. 200 OK response (P-CSCF to UE) - see example in table 6.2-22 

The P-CSCF saves the value of the Service-Route header and associates it with the UE. The P-CSCF then 
forwards the 200 (OK) response from the I-CSCF to the UE indicating that Registration was successful. 

Table 6.2-22: 200 OK response (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Path: 

Service-Route : 

From: 

To: 

Call-ID: 

Contact : 

CSeq: 

Date: 

P-Associated-URI : 

Content-Length : 



6.3 Registration signalling: reregistration - user currently 
registered 

For the purpose of the reregistration signalling flow shown in figure 6.3-1, the subscriber is considered to be roaming. 
The HSS information indicates that the subscriber is registered and authenticated, and that the S-CSCF has been 
allocated to this subscriber. In this signalling flow, the home network does not have network configuration hiding 
active. This flow also shows the authentication of the private user identity. 

This signalling flow assumes: 

1 . That the same PDP Context allocated during the initial registration scenario is still used for reregistration. For 
the case when the UE does not still have an active PDP context then PDP context procedures from 
subclause 16.2 is completed first. 

Editor's Note: If the same PDP-Context is not available, is it guaranteed that the UE will get back the same IP 

address at this point? If this is not possible, would there be a problem with the binding in the P-CSCF 
(user_publicl@homel.net and [5555::aaa:bbb:ccc:ddd])? 

2. The DHCP procedure employed for P-CSCF discovery is not needed. 

3. The S-CSCF selection procedure invoked by the I-CSCF is not needed. 
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Figure 6.3-1 : Reregistration when UE roaming 

1. REGISTER request (UE to P-CSCF) - see example in table 6.3-1 

The registration expires in the UE. The UE reregisters by sending a new REGISTER request. This request is 
sent to the same P-CSCF with which the UE initially registered. The P-CSCF maintains the same binding 
between the public user address (userl_publicl @homel.net) and the host (terminal) address 
([5555::aaa:bbb:ccc:ddd]) which it established during the original registration. 

Table 6.3-1 : REGISTER request (UE to P-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

From; <sip ; userl_publicl@homel .net>;tag=4fa3 

To ; <sip;userl_publicl@homel . net> 

Contact; sip; [5555; ; aaa: bbb; ccc ; ddd] 

Call-ID; apb03aOs0 9dkjdfglkj4 9111 

Authorization; Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 

nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 

uri="sip; registrar .homel . net", response="6629fae49393a05397450978507c4ef 1", integrity- 

protected="yes" 

Security-Client; ipsec-3gpp; alg=hmac-sha-l-96; spi=12345678; portl=1357 

Require; sec-agree 

CSeq; 3 REGISTER 

Supported; path 

Expires; 7200 

Content-Length; 

The header field usage is the same as for the initial registration scenario: 

From: This indicates the public user identity originating the REGISTER request. The public user identity 

may be obtained from the USIM. 

To: This indicates public user identity being registered. This is the identity by which other parties 

know this subscriber. 

Contact: This indicates the point-of-presence for the subscriber - the IP address of the UE. This is the 

temporary identifier for the subscriber that is being registered. Subsequent requests destined for 
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this subscriber will be sent to this address. This information is stored in the P-CSCF and the S- 
CSCF. 

Authorization: It carries authentication information. The private user identity (userl_private@homel.net) is 

carried in the username field of the Digest AKA protocol. As this is a re-registration process, the 
cached information (realm, nonce, algorithm, uri, response) is also sent. 

NOTE 1 : The actual nonce value in the WWW -Authenticate header field is encoded in base64, and it may look 
like:nonce="A34CmH-Fva37UYWpGNB34JP" 

Request-URI: The Request-URI (the URI that follows the method name, "REGISTER", in the first line) indicates 
the destination domain of this REGISTER request. The rules for routing a SIP request describe 
how to use DNS to resolve this domain name ("homel.net") into an address or entry point into the 
home operator's network (the I-CSCF). This information is stored in the USIM. 

Supported: This header is included to indicate to the recipient that the UE supports the Path header. 

Upon receiving this request the P-CSCF will detect that it already has a registration record for this UE and 
will reset it's SIP registration timer for this UE to the Expires time in this request. 

2. DNS:DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
the DNS queries to locate the I-CSCF in the home network. The look up in the DNS is based on the domain 
name specified in the Request URI. The DNS provides the P-CSCF with the address of the I-CSCF in the 
home network. The P-CSCF must not use the I-CSCF address cached as a result of the previous registration. 

3. REGISTER request (P-CSCF to I-CSCF) - see example in table 6.3-3 

This signalling flow shows the REGISTER request being forward from the P-CSCF to the I-CSCF in the 
home domain. 

Table 6.3-3 REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : ; aaa ; bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Path; <sip;pcscfl. visitedl. net; lr> 
Require; path 

P-Visited-Network-ID ; "Visited Network Number 1" 

P-Charging-Vector ; icid-value=a834bcl92f e3; icid-generated-at= [5555 ; ; e9e ; d8d; c7c ;b6b] 
From; 
To; 

Contact ; 
Call-ID; 

Authorization; Digest username = "userl_private@homel . net " , realm="registrar . homel . net " , 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5, 

uri="sip: registrar .homel . net", response="6629fae49393a05397450978507c4ef 1", integrity- 
protected="yes" 
CSeq; 

Supported; 
Expires ; 
Content-Length ; 

Path: This is the P-CSCF URI and is included to inform the S-CSCF where to route terminating 

sessions. 

Require: This header is included to ensure that the recipient correctly handles the Path header. If the 

recipient does not support the path header, a response will be received with a status code of 420 
and an Unsupported header indicating "path". Such a response indicates a misconfiguration of the 
routing tables and the request has been routed outside the IM CN subsystem. 

P-Visited-Network-ID: It contains the identifier of the P-CSCF network at the home network. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with the same unique value 
and the IP address of the P-CSCF that was used in the previous registration. 
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4. Cx: User registration status query procedure 

The I-CSCF requests information related to the Subscriber registration status by sending the private user 
identity, pubHc user identity and visited domain name to the HSS. Because the user has registered, the HSS 
returns the I-CSCF with the S-CSCF address for the subscriber. 

For detailed message flows see 3GPP TS 29.228. 

For the parameters in the REGISTER request (flow 3) which need to be sent to HSS, see table 6.2-5a. 

Table 6.3-4a provides the parameters in the REGISTER request (flow 5), which are obtained from the 
information sent back from the HSS. 

Table 6.3-4a Cx: User registration status query procedure (HSS to I-CSCF) 



IVIessage 

source & 

destination 


Cx Information 
element name 


Mapping to SIP 
header in 
REGISTER 


Description 


HSS to I-CSCF 


S-CSCF name 


Request-URI: 


This information indicates 
the serving CSCF's name 
of that user 



5. REGISTER request (I-CSCF to S-CSCF) - see example in table 6.3-5 

This signalling flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. The Request- 
URI is changed to the address of the S-CSCF. 

Table 6.3-5: REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK2 4 0f 34 .1, SIP/ 2 .0/UDP 
[ 5555 : : aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 
Path: 
Require : 

P-Visited-Network-ID : 
P-Charging-Vector ; 
From; 
To: 

Contact : 
Call-ID: 
Authorization : 
CSeq: 

Supported: 
Expires : 
Content-Length : 



Path: 



The S-CSCF stores the contents of the Path header and uses this URI for routing mobile 
terminated sessions. 



P-Visited-Network-ID: It contains the identifier of the P-CSCF network at the home network. 

Upon receiving this request the S-CSCF will detect that it already has a registration record for this UE and 
will reset it's SIP registration timer for this UE to the Expires time in this request. 

6. Update registration timer 

As the REGISTER request arrived integrity protected, the S-CSCF does not need to challenge the user, but just 
update the registration timer to the value requested by the user (if the policy of the network allows it). 

NOTE: The S-CSCF is allowed to challenge the user. If S-CSCF decides to challenge the user, the call flow will be 
similar to the one presented in section 6.2. 

7. 200 OK response (S-CSCF to I-CSCF) - see example in Table 6.3-7 
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The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful. This 
response will traverse the path that the REGISTER request took as described in the Via list. 

Table 6.3-7 200 OK response (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p.homel . net; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Path: 

Service-Route : <sip:scscfl. homel .net; lr> 
From: 
To: 

Call-ID: 

Contact: <sip: [5555: : aaa:bbb: ccc : ddd] >; expires=7200 
CSeq: 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel .net>, <sip: userl_public3@homel .net>, <sip: +1-2 12-555- 
llll@homel .net; user=phone> 
Content-Length : 

Service-Route: The S-CSCF inserts the Service-Route header value that includes the own S-CSCF URI. 

8. 200 OK response (I-CSCF to P-CSCF) - see example in Table 6.3-8 

The I-CSCF forwards the 200 (OK) response from the S-CSCF to the P-CSCF indicating that Registration was 
successful. This response will traverse the path that the REGISTER request took as described in the Via list. 

Table 6.3-8 200 OK response (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Path: 

Service-Route : 
From: 
To: 

Call-ID: 
Contact : 
CSeq: 
Date: 

P-Associated-URI : 
Content-Length : 

9. 200 OK response (P-CSCF to UE) - see example in Table 6.3-9 

The P-CSCF saves the value of the Service-Route header and associates it with the UE. The P-CSCF then 
forwards 200 (OK) response from the I-CSCF to the UE indicating that Registration was successful. 



Table 6.3-9 200 OK response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

Path: 

Service-Route : 

From: 

To: 

Call-ID: 

Contact : 

CSeq: 

Date: 

P-Associated-URI : 

Content-Length : 



6.4 Registration signalling: mobile initiated deregistration (not 
provided) 
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An example of this flow is not shown in the present document. 

6.5 UE subscription for the registration state event package 

This subclause describes the subscription procedure for the registration state event , whereby the UE requests to be 
notified by the S-CSCF when the event has occurred. This is done using the information structure as indicated in 
3GPPTS 24.229 [16]. 

It is assumed that the user has registered prior to initiating subscription of an event. Also, the subscriber is considered to 
be roaming and the home network operator does not desire to keep its internal configuration hidden from the visited 
network. For this example the trigger point at the P-CSCF for sending out the SUBSCRIBE request is the 200 (OK) 
response of the user's registration. 



Visited Networl< (visitedl .net) 



Home Networi^ (tiomel .net) 



UE 



RAN 



GPRS /DHCP 



LSUBSCFilBE 



4. 202 (Accspted) 



6. NOTIFY 



7. 200 (OK) 



P-CSCF 
(pcscfl) 



DNS 



l-CSCF 
{icscf1_p) 



2. SUBSCRIBE 



S-CSCF 
(scscfl) 



3. 202 (Acceipted) 



5. NOTIi-Y 



8. 200 (OK) 



Figure 6.5-1 : UE subscription for the registration state event package 
(without l-CSCF providing configuration independence) 

1. SUBSCRIBE request (UE to P-CSCF) - see example in table 6.5-1 

The UE sends the SUBSCRIBE request for the reg event package. 

Table 6.5-1 : SUBSCRIBE request (UE to P-CSCF) 

SUBSCRIBE sip: userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 

Privacy: none 

From: <sip : userl_publicl@homel .net>;tag=31415 

To: <sip : userl_public@homel . net> 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 61 SUBSCRIBE 

Event : reg 

Expires: 7200 

Accept : application/cpim-pidf +xml 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] > 

Content-Length: 

From: The user does not require privacy, the From header contains the value requested by the user. 

Privacy: The user does not require privacy, therefore the Privacy header is set to the value "none" as 

specified in draft-ietf-sip-asserted-identity [17] and draft-ietf-sip-privacy-general [13]. 
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P-Asserted-Identity: The user provides a hint about the identity to be used for this session. 

Event: This field is populated with the value 'reg' to specify the use of the registration state package. 

Accept: This field is populated with the value 'application/cpim-pidf+xml'. 

Upon receiving the SUBSCRIBE request, the P-CSCF stores the following information about this dialog, for 
use in possible error recovery actions - see example in table 6.5-lb. 

Table 6.5-1 b: Storage of information at P-CSCF 



Request-URI ; sip : userl_publicl@homel .net 

From; sip ; userl_publicl@homel .net;tag=31415 

To; sip ; userl_public@homel . net 

Call- ID; b8 9r jhnedlrf jflslj40a222 

Cseq(2dest); 61 SUBSCRIBE 

Cseq(2orig) ; none 

Contact (orig); sip; [5555;; aaa;bbb; ccc ; ddd] 



2. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table 6.5-2 

P-CSCF looks up the serving network information for the public user identity that was stored during the 
registration procedure. The SUBSCRIBE request is forwarded to the S-CSCF. 

Table 6.5-2: SUBSCRIBE request (P-CSCF to S-CSCF) 

SUBSCRIBE sip;userl_publicl@homel.net SIP/2.0 

Via; SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa;bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 
Route; sip; scscf 1 .homel . net; Ir 
Record-Route ; sip;pcscfl. homel . net ; Ir 

P-Asserted-Identity ; "John Doe" <sip;userl_publicl@homel . net> 

P-Charging-Vector ; icid-value=a834bcl92f e3; icid-generated-at= [5555 ; ; e9e ; d8d; c7c ;b6b] 
Privacy ; 
From; 
To; 

Call-ID; 
CSeq; 
Event ; 
Expires : 
Accept : 
Contact : 
Content-Length ; 

Route: Contains the elements from the Path header from registration. 

P-Asserted-Identity: The P-CSCF inserts this header based on the user's hint present in the incoming P-Asserted- 
Identity header. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

Upon receiving the INVITE, the S-CSCF stores the following information about this session, for use in 
possible charging and error recovery actions - see example in table 6.5-2b. 

Table 6.5-2b: Storage of information at S-CSCF 



! Request-URI; sip;userl_publicl@homel . net 






■ From; sip ; userl_publicl@homel . net ; tag=31415 






1 To; sip ; userl_public@homel . net 






: Call-ID; b89rjhnedlrf jflslj40a222 






i Cseq(2dest); 61 SUBSCRIBE 






; Cseq(2orig) ; none 






I P-Charging-Vector ; icid-value=a834bcl92f e3; icid-generated-at= 


[5555; 


;e9e;d8d;c7c;b6b] ! 


1 Route (2orig) ; sip ; pcscf 1 . homel . net 






! Contact (orig) ; sip; [5555 ;; aaa;bbb; ccc; ddd] 
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3. 202 (Accepted) response (S-CSCF to P-CSCF) - see example in table 6.5-3 

The S-CSCF sends an acknowledgement towards the UE indicating that the subscription was successful. This 
response will traverse the path that the SUBSCRIBE request took as described in the Via list. 

NOTE 1: If the S-CSCF can process the SUBSCRIBE request and send the NOTIFY request immediately, it can 
send a 200 (OK) response instead of a 202 (Accepted) response. 

Table 6.5-3: 202 (Accepted) response (S-CSCF to P-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; sip;pcscfl. homel .net; Ir 

P -Asserted- Identity ; <sip;scscfl. homel . net> 
Privacy: none 
From; 

To ; <sip : userl_publicl@homel .net>;tag=151170 
Call-ID: 
CSeq: 
Event : 
Expires : 

Contact: sip: scscfl .homel . net 
Content-Length : 

Expires: If the value of the Expires header in SUBSCRIBE request is different from the one received in 

REGISTER method, then the value of Expires header in the 202 (Accepted) response is set to match the 
value of Expires header in REGISTER method. 

4. 202 (Accepted) response (P-CSCF to UE) - see example in table 6.5-4 

P-CSCF sends the response to UE. 

Table 6.5-4: 202 (Accepted) response (P-CSCF to UE) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Event : 

Expires : 

Contact : 

Content-Length : 

5. NOTIFY request (S-CSCF to P-CSCF) - see example in table 6.5-5 

The S-CSCF sends a first NOTIFY request towards the UE in order to inform the UE about the registration 
status of the monitored user. 

In the example below, the NOTIFY request specifies the following public user identity as registered 
(i.e. status=open): sip:userl_publicl@homel.net, tel: H-498972233114. 

The following public user identity has been deregistered (i.e. status=closed) sip:userl_public2@homel.net. 
They are arranged in the preferred order of priority in this example. 

The Route header is constructed from the information saved at registration. 

Table 6.5-5: NOTIFY request (S-CSCF to P-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route: sip:pcscfl .homel . net; Ir 

From: <sip : userl_publicl@homel .net>;tag=31415 
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To: <sip:userl_publicl@homel . net>; tag=151170 

Call-ID: 

CSeq: 42 NOTIFY 

Subscript ion- St ate : active; expires=72 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Contact: sip: scscf 1 .homel . net 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 

<status><basic>open</basic></status> 
</tuple> 

< tuple name="sip : userl_public2@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

<tuple name="tel:+4 98 972233114"> 

<status><basic>open</basic></status> 
</tuple> 

</presence> 



From: 



The tag of this field matches that of the To; field in the received 200/202 response for the 
SUBSCRIBE request. 



Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or 'application/cpim- 
pidf+xml' if the Accept header was not present in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the subscriber's registration state is formed as indicated in 
3GPPTS 24.229 [16]. 

6. NOTIFY request (P-CSCF to UE) - see example in table 6.5-6 

The P-CSCF forwards the NOTIFY request to the UE. 

Table 6.5-6: NOTIFY request (P-CSCF to UE) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Max-Forwards: 69 

From: 

To: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Content-Type : 

Contact : 

Content-Length : 

7. 200 (OK) response (UE to P-CSCF) - see example in table 6.5-7 

The UE generates a 200 (OK) response to the NOTIFY request. 

Table 6.5-7 200 (OK) response (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. 200 (OK) response (P-CSCF to S-CSCF) - see example in table 6.5-8 
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P-CSCF forwards the 200 (OK) to the S-CSCF. 

Table 6.5-8: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length : 



6.6 P-CSCF subscription for the registration state event 
package (without l-CSCF providing configuration 
independence) 

This section describes the subscription procedure for the network initiated deregistration event, whereby the P-CSCF 
requests to be notified by the S-CSCF when the event has occurred. This is done using the 'reg' package as described in 
3GPPTS 24.229 [16]. 

It is assumed that the user has registered prior to initiating subscription of an event. Also, the subscriber is considered to 
be roaming and the home network operator does not desire to keep its internal configuration hidden from the visited 
network. For this example the trigger point at the P-CSCF for sending out the SUBSCRIBE request is the 200 (OK) 
response of the user's registration. 



Visited Networl< (visitedl .net) 



Home Networi< (tiomel .net) 



UE 



RAN 



GPRS /DHCP 



P-CSCF 
(pcscfl) 



DNS 



l-CSCF 
(icscf1_p) 



I.SUBSCI^IBE 



2. 202 (Accepted) 



3. NOTII-Y 



4. 200 (ClK) 



S-CSCF 
(scscf 1) 



Figure 6.6-1 : P-CSCF subscription for the registration state event package 
(without l-CSCF providing configuration independence) 

1. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table 6.6-1 

The P-CSCF sends the SUBSCRIBE request for the reg event package. 

Table 6.6-1 : SUBSCRIBE request (P-CSCF to S-CSCF) 

SUBSCRIBE sip: userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl . net;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

P -Asserted- Identity : <sip:pcscfl. visitedl. net> 

Privacy: none 

From: <sip: pcscfl. visitedl. net>;tag=314 15 

To : <sip:userl_publicl@homel . net> 

Call-ID: dre36d2v32gnlgiiomm72445 

CSeq: 61 SUBSCRIBE 

Event : reg 

Expires: 7200 

Accept : application/cpim-pidf +xml 

Contact : <sip:pcscfl .visitedl . net> 

Content-Length: 
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From: This header is populated with the SIP URI that identifies the P-CSCF. 

Contact: This is where the NOTIFY requests for this subscription will be sent. It consists of the SIP URL- 

escaped public user identity at the P-CSCF. 

Event: This field is set to the value 'reg' to specify the use of the reg package. 

Accept: This field is set to the value 'application/cpim-pidf-nxml'. 

2. 202 (Accepted) response (S-CSCF to P-CSCF) - see example in table 6.6-2 

The S-CSCF sends an acknowledgement towards the P-CSCF indicating that the subscription was successful. 
This response will traverse the path that the SUBSCRIBE request took as described in the Via list. 

NOTE 1: If the S-CSCF can process the SUBSCRIBE request and send the NOTIFY request immediately, it can 
send a 200 (OK) response instead of a 202 (Accepted) response. 

Table 6.6-2: 202 (Accepted) response (S-CSCF to P-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

P -Asserted- Identity ; <sip:scscfl. homel . net> 
Privacy: none 
From: 

To : <sip : userl_publicl@homel .net>;tag=151170 
Call-ID: 
CSeq: 

Contact: sip: scscfl .homel . net 
Event : 
Expires : 
Content-Length : 

Expires: If value of the Expires header in SUBSCRIBE request is different from the one received in REGISTER 
method, then the value of Expires header in the 202 (Accepted) response is set to match the value of 
Expires header in REGISTER method. 

3. NOTIFY request (S-CSCF to P-CSCF) - see example in table 6.6-3 

The S-CSCF sends a first NOTIFY request towards the P-CSCF in order to inform the P-CSCF about the 
registration status of monitored user. 

Table 6.6-3: NOTIFY request (S-CSCF to P-CSCF) 

NOTIFY sip:pcscfl. visitedl. net SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

From: <sip : userl_publicl@homel .net>;tag=151170 

To : <sip:userl_publicl@pcscf 1 .visitedl . net>; tag=31415 

Call-ID: dre36d2v32gnlgiiomm72445 

CSeq: 42 NOTIFY 

Subscript ion- St ate : active; expires=72 00 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Contact: sip: scscfl .homel . net 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

</presence> 

From: The tag of this field matches that of the To; field in the received 200/202 response for the 

SUBSCRIBE request. 

Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or 'application/cpim- 
pidf H-xml' if the Accept header was not present in the SUBSCRIBE request. 
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The message body in the NOTIFY request that carries the subscriber's registration state is formed as indicated in 
3GPPTS 24.229 [16]. 

4. 200 (OK) response (P-CSCF to S-CSCF) - see example in table 6.6-4 

P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table 6.6-4: 200 (OK) response (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From; 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length: 



6.7 Notifying of the network-initiated de registration event 
6.7.1 Network-! nitiatecd cJeregistration event occurs in the S-CSCF 

Figure 6.7.1-1 assumes that the UE and the P-CSCF both have subscribed for the user's registration state event package 
according to subclause 6.5 and shows how the UE and the P-CSCF are notified when the network-initiated 
deregistration event occurs in the S-CSCF. 

Also, it is assumed that the home network does not have network configuration hiding active. 
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Figure 6.7.1-1 : Network Initiated Deregistration event occurs in the S-CSCF 

1 . Network Initiated Deregistration event occurs in the S-CSCF 

2. S-CSCF deregistration notification 

When the Network Initiated Deregistration Event occurs in the S-CSCF, the S-CSCF informs the HSS that 
the user is no longer registered. The S-CSCF either notifies the HSS to clear or requests to keep its location 
information for that subscriber. The HSS then either clears or keeps the S-CSCF name for that subscriber 
according to request. In both cases the state of the subscriber identity is stored as unregistered in the HSS and 
the S-CSCF. The HSS acknowledges the request. 

For detailed message flows see 3GPP TS 29.228 [11]. 

3 SIP NOTIFY request (S-CSCF to P-CSCF) - see example in table 6.7.1-3 
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After the S-CSCF deregistration notification procedure the S-CSCF immediately sends a NOTIFY request 
towards the UE in order to inform about the network initiated deregistration. The same Request URI, To, 
From, Call-ID are used as in the first NOTIFY request. CSeq is incremented since this is the second NOTIFY 
request sent towards the UE. 

Table 6.7.1-3: SIP NOTIFY request (S-CSCF to P-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route : sip:pcscfl.visitedl.net;lr 

From: <sip : userl_publicl@homel .net>;tag=151170 

To : <sip : userl_publicl@homel .net>;tag=31415 

Call- ID: b8 9r jhnedlrf jflslj4 0a222 

CSeq: 43 NOTIFY 

Subscription-State: terminated 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Contact: sip: scscf 1 .homel . net 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "You have been deregistered from the network, please register again"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

<tuple name="sip:userl_public2@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

<tuple name="tel:+4 98 972233114"> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This ID has been automatically deregistered"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

</presence> 

4. SIP NOTIFY request (P-CSCF to UE) - see example in table 6.7.1-4 

P-CSCF forwards the NOTIFY request to the UE. 

Table 6.7.1-4: SIP NOTIFY request (P-CSCF to UE) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1 

Max-Forwards: 69 

From: 

To: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Content-Type : 

Contact : 

Content-Length : 

5. 200 (OK) response (UE to P-CSCF) - see example in table 6.7.1-5 

Table 6.7.1-5: SIP 200 (OK) response (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



6. SIP 200 (OK) response (P-CSCF to S-CSCF) - see example in table 6.7.1-6 

Table 6.7.1-6: SIP 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



7 SIP NOTIFY request (S-CSCF to P-CSCF) - see example in table 6.7.1-7 

After sending the Cx.Put request the S-CSCF also immediately sends a NOTIFY request towards the P- 
CSCF to which the UE is attached to, in order to inform about the network initiated deregistration. The same 
Request URI, To, From, Call-ID are used as in the first NOTIFY request. CSeq is incremented since this is 
the second NOTIFY request sent towards the P-CSCF. 

Table 6.7.1-7: SIP NOTIFY request (S-CSCF to P-CSCF) 

NOTIFY sip:pcscfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

From: <sip : userl_publicl@homel .net>;tag=151170 

To: <sip:pcscfl.visistecll.net>;tag=31415 

Call- ID: dre3 6d2v32gnlgiiomm72445 

CSeq: 43 NOTIFY 

Subscription-State: terminated 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Contact: sip : scscf 1 . homel . net 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This public ID has been deregistered by the network"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

< tuple name="sip : userl_public2@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

<tuple name="tel:+4 98 972233114"> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This ID has been automatically deregistered"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

</presence> 

8. SIP 200 (OK) response (P-CSCF to S-CSCF) - see example in table 6.7.1-8 

Table 6.7.1-8: SIP 200 (OK) response (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 
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Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



6.7.2 Network-initiated deregistration event occurs in tlie HSS 

Figure 6.7.2-1 assumes that the UE and the P-CSCF both have subscribed for the user's registration state event package 
according to subclause 6.5 and shows how the UE and the P-CSCF are notified when the Network Initiated 
Deregistration event occurs in the HSS. 

Also, it is assumed that the home network does not have network configuration hiding active. 



Visited Networl< 
(visitedl .net) 



HomeNetworl< 
(iDirel .net) 




Figure 6.7.2-1 : Network-initiated deregistration event occurs in the IHSS 

1 . Network-initiated deregistration event occurs in the HSS 

2. Cx-Deregister 

HSS initiates the deregistration, sending a Cx-Deregister (subscriber identity). For detailed message flows 
see 3GPP TS 29.228 [11]. 

3. SIP NOTIFY request (S-CSCF to P-CSCF) - see example in table 6.7.2-3 

After getting the Cx-Deregister message the S-CSCF immediately sends a NOTIFY request towards the UE 
order to inform about the network initiated deregistration. The same Request URl, To, From, Call-ID are 
used as in the first NOTIFY request. CSeq is incremented since this is the second NOTIFY request sent 
towards the UE. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 57 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Table 6.7.2-3: SIP NOTIFY request (S-CSCF to P-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route : sip:pcscfl.visitedl.net;lr 

From: <sip : userl_publicl@homel . net>; tag=151170 

To : <sip:userl_publicl@homel . net>; tag=31415 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 43 NOTIFY 

Subscription-State: terminated 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Contact: sip : scscf 1 . homel . net 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "You have been deregistered from the network, please register again"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

< tuple name="sip : userl_public2@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

<tuple name="tel:+4 98 972233114"> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This ID has been automatically deregistered"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

</presence> 

4. SIP NOTIFY request (P-CSCF to UE) - see example in table 6.7.2-4 

P-CSCF forwards the NOTIFY request to the UE. 

Table 6.7.2-4: SIP NOTIFY request (P-CSCF to UE) 

NOTIFY sip: [5555: :aaa:bbb:ccc:dddl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Max-Forwards: 69 

From: 

To: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Content-Type : 

Contact : 

Content-Length : 

5. 200 (OK) response (UE to P-CSCF) - see example in table 6.7.2-5 

Table 6.7.2-5: SIP 200 (OK) response (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net;branch=z9hG4bK240f 34 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 
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6. SIP 200 (OK) response (P-CSCF to S-CSCF) - see example in table 6.7.2-6 

Table 6.7.2-6: SIP 200 (OK) response (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length : 

7 SIP NOTIFY request (S-CSCF to P-CSCF) - see example in table 6.7.2-7 

After receiving the 200 (OK) response from the UE the S-CSCF also immediately sends a NOTIFY request 
towards the P-CSCF to which the UE is attached to, in order to inform about the network initiated 
deregistration. The same Request URI, To, From, Call-ID are used as in the first NOTIFY request. CSeq is 
incremented since this is the second NOTIFY request sent towards the P-CSCF. 

Table 6.7.2-7: SIP NOTIFY request (S-CSCF to P-CSCF) 

NOTIFY sip:pcscfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=151170 

To: <sip:pcscfl.visistedl .net>; tag=31415 

Call-ID: dre36d2v32gnlgiiomm72445 

CSeq: 43 NOTIFY 

Subscript ion- St ate : active; expires=72 

Event : reg 

Contact: sip : scscf 1 . homel . net 

Content-Type : application/cpim-pidf ixml 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This public ID has been deregistered by the network"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

< tuple name="sip : userl_public2@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

<tuple name="tel:+4 98 972233114"> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This ID has been automatically deregistered"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

</presence> 

8. SIP 200 (OK) response (P-CSCF to S-CSCF) - see example in table 6.7.2-8 

Table 6.7.2-8 SIP 200 (OK) response (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 
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9. Cx-Deregister Resp 

After receiving the 200 (OK) response from the P-CSCF, the S-CSCF sends Cx-Deregister Resp to the HSS. 
For detailed message flows see 3GPP TS 29.228 [11]. 

6.7.3 Network-initiated deregistration upon UE roaming and registration to 
a new network - assumes tiiat {he previous registration lias not 
expired 

This shows the registration signalling flow for the scenario that the UE loses the GPRS attachment in current visited 
access network and roams to makes a new GPRS attachment in a new visited access network without deregistration 
from its previous network. The GGSN and P-CSCF are assumed to be in the visited network. When the UE starts 
registration in via the new visited access network and P-CSCF, the home S-CSCF in the home IMS network initiates the 
deregistration to the P-CSCF in the previous visited network. It is assumed that the old P-CSCF has subscribed the 
event package to the S-CSCF and the subscription has not expired. For the reason of simplicity, the authentication 
procedure is not shown because it has no technical impact on this flow. 
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Figure 6.7.3-1 : Network-initiated deregistration upon UE roaming without deregistration 

Flows from 1 to 4 are the same as those in subclause 6.2. 
5. Cx: User Registration Status Query 
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The I-CSCF sends the Cx-Query signalling flow to the HSS (Visited Network Identifier, subscriber identity, 
home domain name,). Because user has not deregistered with its previous network, so that HSS finds a S- 
CSCF assigned for that user and treats this as a re-registration procedure. Therefore, the HSS returns the S- 
CSCF name to the I-CSCF.For detailed message flows see 3GPP TS 29.228 [11]. 

For the parameters in the REGISTER request (flow 4) which need to be sent to HSS, see table 6.2-4a. 

Table 6.3-4a provides the parameters in the REGISTER request (flow 6) which are obtained from the 
information sent back from the HSS. 

6. REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the REGISTER request to the S-CSCF assigned to that user. 

7. Cx-S-CSCF Registration Notification 

The S-CSCF notifies the HSS to update its location information for that subscriber. The HSS sends a 
response to the S-CSCF to acknowledge the update of location information and also with the user profile. 

9. NOTIFY request (S-CSCF to Old P-CSCF) - see example in table 6.7.3-9 

Upon receiving flow 6, the S-CSCF found that the P-CSCF address in that message is different with the one 
in its database, so that the S-CSCF knows that the UE has left its previous P-CSCF without deregister itself. 
And the old P-CSCF has subscribed with the registration event package for that user, therefore, the S-CSCF 
sends a NOTIFY request to that P-CSCF. 

Table 6.7.3-9: SIP NOTIFY request (S-CSCF to Old P-CSCF) 

NOTIFY sip:pcscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards; 70 

From: <sip : userl_publicl@homel . net>; tag=151170 

To: <sip:pcscfl.visistedl .net>; tag=31415 

Call-ID: dre36d2v32gnlgiiomm72445 

CSeq: 43 NOTIFY 

Subscription-State: terminated 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Contact: sip: scscf 1 .homel . net 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This public ID has been deregistered by the network"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

< tuple name="sip : userl_public2@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

<tuple name="tel:+4 98 972233114"> 
<status><basic>closed</basic> 
<note> 

reason-phrase: "This ID has been automatically deregistered"; 
registrar: registrar.homel.net 
</note> 
</status> 
</tuple> 

</presence> 

10. SIP 200 (OK) response (Old P-CSCF to S-CSCF) - see example in table 6.7.3-10 

Upon receiving the NOTIFY request, the P-CSCF discards any information binding with that user. 
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Table 6.7.3-10: SIP 200 (OK) response (Old P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



6.8 



Network initiated re-authentication 



This subclause describes the notification of a UE that occurs when the S-CSCF assigned to that user requests re- 
authentication. 

It is assumed that user has registered and also subscribed to the registration state event before. Also, the subscriber is 
considered to be roaming and the home network operator does not desire to keep its internal configuration hidden from 
the visited network. 

After this procedure the user's UE might automatically initiate re-registration procedures. If the user fails to re-register, 
the public user identity for which re-authentication is requested, the public user identity may be deregistered by S- 
CSCF. 
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Figure 6.8-1 : S-CSCF informs UE about network-initiated re-authentication event 
(without l-CSCF providing configuration independence) 

1 . Network initiated re-authentication (S-CSCF) 

The network initiated re-authentication event for the private user identity of the user occurs at the S-CSCF. 
As the user has subscribed to the registration state event package this is the trigger point for the S-CSCF to 
notify the user about the event occurrence. 

2. SIP NOTIFY request (S-CSCF to P-CSCF) - see example in table 6.8-2 

The S-CSCF sends a NOTIFY request towards the UE in order to inform the UE about the occurrence of the 
network initiated re-authentication event. 

The Route header is constructed from the information saved at registration. 

Table 6.8-2: SIP NOTIFY request (S-CSCF to P-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route : sip:pcscfl. visitedl. net;lr 

From: <sip : userl_publicl@homel . net>; tag=31415 

To : <sip:userl_publicl@homel . net>; tag=151170 

Call- ID: b8 9r jhnedlrf jflslj40a222 
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CSeq: 43 NOTIFY 

Subscript ion- St ate ; active; expires=72 

Event ; reg 

Content-Type ; application/cpim-pidf +xml 

Contact: sip: scscf 1 .homel . net 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : " 

xmlns : registration="urn: ietf: params : xml : ns : cpim-pidf : registration"> 

< tuple name="sip : userl_publicl@homel . net "> 
<status> 

<basic>open</basic> 

<registration>re-authenticate</registration> 
</status> 
</tuple> 
</presence> 

From: The tag of this field matches that of the To; field in the received 200/202 response for the 

SUBSCRIBE request. 

Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or 'application/cpim- 
pidf+xml' if the Accept header was not present in the SUBSCRIBE request. 

The message body in NOTIFY request that carries the subscriber's registration state is formed as indicated in 
3GPPTS 24.229 [16]. 

3. SIP NOTIFY request (P-CSCF to UE) - see example in table 6.8-3 

The P-CSCF forwards the NOTIFY request to UE. 

Table 6.8-3: SIP NOTIFY request (P-CSCF to UE) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Max-Forwards: 69 

From: 

To: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Content-Type : 

Contact : 

Content-Length : 

4. SIP 200 (OK) response (UE to P-CSCF) - see example in table 6.8-4 

The UE generates a 200 (OK) response to the NOTIFY request. 

Table 6.8-4: SIP 200 (OK) response (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

5. SIP 200 (OK) response (P-CSCF to S-CSCF) - see example in table 6.8-5 

P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table 6.8-5: SIP 200 (OK) response (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 
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Call-ID: 
CSeq: 
Content-Length : 



6. Re-authentication (UE) 

The UE now initiates re-authentication procedures. 

6.9 Registration error conditions 

6.9.1 Reregistration - failure of reregistration 

See subclause 16.9.1. 

6.9.2 User not registered, user not allowed to roam / user unknown 



UE 



RAN 



Visited Networl< (visitedl .net) 
GPRS /DHCP 



iHome Networl^ (home1.net) 



P-CSCF 



DNS 



1. GPRS: PDP Context 
Establistiment and 
P-CSCF discovery 



2. REGISTER 



8. 403 (Forbidden) 



3. DNS: 
DNS-Q 



7.403 



l-CSCF 



S-CSCF 



HSS 



4. F^EGISTER 



5. Cx: User Registration 
Status Query 



6. Roaming not 

allowed / user 

unl<nown 



Forbidden) 



Figure 6.9.2-1 : Registration failure: User not registered, user not allowed to roam 

The first five steps are similar with the regular Registration signalling flows described in subclause 6.2. 

The "Roaming not allowed" and "User unknown" error conditions would result in the same signalling flow (only the 
actions taken by I-CSCF will difl'er), thus the signalling flows are merged and only the I-CSCF action is described 
depending on the error condition. 

6. Roaming not allowed / User unknown 

The information received as a response to the Cx-Query may indicate that "Roaming is not allowed" for the 
subscriber from the visitedl.net network. In this case I-CSCF needs to send a 403 (Forbidden) response back 
to the UE. I-CSCF will insert a warning header in the response, indicating to the UE the reason of refusing 
the Registration request. Warning header will contain the name of the network inserting the warning header 
(warn-agent = homel.net) and in addition it may contain a warn-text.The warn-code inserted into the 
Warning header is 399. 

When the information received as a response to the Cx-Query indicates that the subscriber is unknown to the 
network or the subscriber does not have a valid subscription, the I-CSCF needs to send a 403 (Forbidden) 
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response back to the UE. I-CSCF will insert a warning header in the response, indicating to the UE the reason 
of refusing the Registration request. Warning header will contain the name of the network inserting the 
warning header (warn-agent = homel.net) and in addition it may contain a warn-text. The warn-code inserted 
into the Warning header is 399. 

7. 403 (Forbidden) response (I-CSCF to P-CSCF) - see example in table 6.9.2-7 

Table 6.9.2-7: 403 (Forbidden) response (I-CSCF to P-CSCF) 

SIP/2.0 403 Forbidden 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd) ; branch=z9hG4bKnashds7 

Warning; 399 homel.net "Roaming not allowed from this network" 

From: 
To: 

Call-ID: 
Cseq: 
Content-Length: 

8. 403 (Forbidden) response (P-CSCF to UE) - see example in table 6.9.2-8 

Table 6.9.2-8: 403 (Forbidden) response (P-CSCF to UE) 

SIP/2.0 403 Forbidden 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Warning: 399 homel.net "Roaming not allowed from this network" 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



6.9.3 Registration failure - user autinentication failure 

This clause (see figure 6.9.3-1) shows the signalling flow with user authentication failure at step 19 of subclause 6.2 
"Signalling flows for REGISTER" and a final failure of the authentication at step 30. 
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UE 
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Figure 6.9.3-1 : User authentication failure 
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Steps 1 through 17 are the same as the signalHng flow in subclause 6.2. 

18. Authentication: User authentication fails 

Upon receiving the REGISTER request carrying the authentication response, RES, the S-CSCF checks that 
the user's active XRES matches the received RES. If the check is unsuccessful then this authentication 
challenge fails and the public user identity is not yet registered in the S-CSCF. 

At this point the S-CSCF has the option of repeating a number of authentication challenges as given in step 
18 through 28. For the purposes of this flow, only one repetition is shown. 

19. Cx. S-CSCF registration notification 

The S-CSCF selects new authentication vectors as specified in step 9, either from the list already within the 
S-CSCF, or by requesting new vectors from the HSS. 

20. 401 (Unauthorized) response (S-CSCF to I-CSCF) - see example in table 6.9.3-20 

The authentication challenge is sent in the 401 (Unauthorized) response towards the UE. 

Table 6.9.3-20: 401 (Unauthorized) response (S-CSCF to I-CSCF) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From; <sip ; userl_publicl@homel .net>;tag=4fa3 
To: <sip:userl_publicl@homel . net>; tag=5ef4 
Call-ID: apb03a0s0 9dkjdfglkj4 9111 

www-Authenticate: Digest realm="registrar .homel . net ", nonce=base64 (RAND + AUTN + server specific 
data) , algorithm=AKAvl-MD5, ik="00112233445566778899aabbccddeef f " , 
ck="ffeeddccbbaall22334455667788 9900" 
CSeq: 2 REGISTER 
Content-Length: 

NOTE: The actual nonce value in the WWW -Authenticate header field is encoded in base64, and it may look 
like:nonce="AYH-3fUYo021QilMnv3C6qAzEp4502" 

21. 401 (Unauthorized) response (I-CSCF to P-CSCF) - see example in table 6.9.3-21 

The authentication challenge is sent in the 401 (Unauthorized) response towards the UE. 

Table 6.9.3-21 : 401 (Unauthorized) response (I-CSCF to P-CSCF) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 
To: 

Call-ID: 

www-Authenticate : 
CSeq: 
Content-Length : 

22. 401 (Unauthorized) response (P-CSCF to UE) - see example in table 6.9.3-22 

The P-CSCF removes any keys received in the 401 (Unauthorized) response and forwards the rest of the 
response to the UE. 

Table 6.9.3-22: 401 (Unauthorized) response (P-CSCF to UE) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

www-Authenticate: Digest realm="registrar . homel . net " , nonce=base64 (RAND + AUTN + server specific 

data) , algorithm=AKAvl-MD5 

Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 
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CSeq: 

Content-Length : 



WWW-Authenticate: The P-CSCF removes the ik and ck parameters (directives) from the header. 

23. Generation of response and session keys at UE 

Upon receiving the Unauthorised response, the UE extracts the MAC and the SQN from the AUTN. The UE 
calculates the XMAC and checks that XMAC matches the received MAC and that the SQN is in the correct 
range. If both these checks are successful the UE calculates the response, RES, and also computes the session 
keys IK and CK. The RES is put into the Authorization header and sent back to the registrar in the 
REGISTER request. 

24. REGISTER request (UE to P-CSCF) - see example in table 6.9.3-24 



Table 6.9.3-24: REGISTER request (UE to P-CSCF) 



REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

From; <sip ; userl_publicl@homel .net>;tag=4fa3 

To ; <sip;userl_publicl@homel . net> 

Contact; <sip; [5555; ; aaa; bbb; ccc ; ddd] > 

Call-ID; apb03a0s0 9dkjdfglkj4 9111 

Authorization; Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 

nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 

uri="sip; registrar .homel . net", response="0alb04c89e54f09ab45e84d30e29f83a" 

Security-Verify; ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

CSeq; 3 REGISTER 

Expires; 7200 

Supported; path 

Content-Length; 

Authorization: This carries the response to the authentication challenge received in step 12 along with the private 
user identity, the realm, the nonce, the URI and the algorithm. 

25. DNS: DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
the DNS queries to locate the I-CSCF in the home network. The look up in the DNS is based on the domain 
name specified in the Request URI. 

The P-CSCF sends the REGISTER request - after local processing - to the address indicated in the Request- 
URI. When forwarding the REGISTER request the P-CSCF needs to specify the protocol, port number and 
IP address of the I-CSCF server in the home network to which to send the REGISTER request. The P-CSCF 
tries to find this information by querying the DNS. Since the Request-URI does not specify a numeric IP 
address, and the transport protocol and port are not indicated, the P-CSCF performs an NAPTR query for the 
domain specified in the Request-URI. 



Table 6.9.3-25a DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME=registrar. homel. net, QCLASS=IN, QTYPE=NAPTR 



The DNS records are retrieved according to RFC 3263 [14]. 

Table 6.9.3-25b DNS Query Response (DNS to P-CSCF) 



: OPCODE=SQUERY, RESPONSE, AA 










: QNAME=registrar. homel. net, QCLASS=IN, 


QTYPE=NAPTR 








: registrar.homel.net IN NAPTR 


50 50 "s" 


"SIP+D2U" 


"" _sip.. 


_udp.registrar.homel.net I 


! IN NAPTR 


90 50 "s" 


"SIP+D2T" 


"" ^sip._ 


_tcp.registrar.homel.net i 


1 IN NAPTR 


100 50 "s" 


"SIPS+D2T" 


"" _sips 


._tcp.registrar.homel.net ; 
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Since the UDP is prefered, the P-CSCF finds the I-CSCF by a DNS SRV lookup according to RFC 2782 [4]. 
Table 6.9.3-25c: DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME= sip._udp.registrar.homel.net, QCLASS=IN, QTYPE=SRV 



The DNS records are retrieved according to RFC 2782 [4]. 

Table 6.9.3-25d: DNS Query Response (DNS to P-CSCF) 



: OPCODE=SQUERY, RESPONSE, AA 

! QNAME= sip._udp. registrar .homel 


net. 


QCLASS=IN, 


QTYPE=SRV 




; _sip._udp.registrar.homel.net 




IN SRV 
IN SRV 


1 10 5060 
1 5060 


icscfl_p. homel . net 
icscf7_p. homel . net 


j icscfl_p.homel.net 
I icscf7_p.homel.net 






IN AAAA 
IN AAAA 


5555: :aba 
5555: :ala 


dab : aaa : daa 
b2b:c3c:d4d 



In the Answer field of the query-response each I-CSCF is identified by its host domain name. The returned 
SRV Resource Records (RRs) are merged and ordered, and the selection technique (employing the Priority 
and Weight parameters returned in the RRs) as specified in RFC 2782 [4] is used to select the I-CSCF 
(i.e. the icscfl_p.homel.net). Since the Additional Data field of the query -response also contains the IP 
address of the selected I-CSCF (i.e. 5555::aba:dab:aaa:daa), a new query to the DNS is not required. 

Once the IP address of the I-CSCF is obtained, the P-CSCF forwards the REGISTER request to this IP 
address (i.e. 5555::aba:dab:aaa:daa) using the UDP protocol and port number 5060. 

26. REGISTER request (P-CSCF to I-CSCF) - see example in table 6.9.3-26 

This signalling flow shows the REGISTER request being forwarded from the P-CSCF to the I-CSCF in the 
home domain. 

Table 6.9.3-26: REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel. net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 69 

Path: <sip:pcscfl. visitedl. net; lr> 

Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P-Charging-Vector : icid-value=a834bcl92f eS; icid-generated-at= [5555 : : e9e : d8d: c7c : b6b] 

From: 

To: 

Contact : 

Call-ID: 

Authorization: Digest username="userl_private@homel . net " , realm="registrar . homel . net " , 
nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 
uri=" sip: registrar. homel .net", response="0alb04c8 9e54f0 9ab4 5e84d30e2 9f83a", 
integrity-protected="yes" 

CSeq: 

Supported: 

Expires : 

Content-Length : 

Path: This is the P-CSCF URI and is included to inform the S-CSCF where to route terminating 

sessions. 

27. Cx: User registration status query procedure 

The I-CSCF requests information related to the Subscriber registration status by sending the private user 
identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF required 
capabilities and the I-CSCF uses this information to select a suitable S-CSCF. 

For detailed message flows see 3GPP TS 29.228 [11]. 
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Table 6.9.3-27a provides the parameters in the REGISTER request (flow 5) which need to be sent to HSS. 
Table 6.9.3-27a Cx: User registration status query procedure (l-CSCF to HSS) 



Message 

source & 

destination 


Cx Information 
element name 


Information 

Source in 

REGISTER 

request 


Description 


l-CSCF to HSS 


Private User 
Identity 


Authorization: 


The Private User Identity is 
encoded in the username 
field according to the 
Authorization protocol. 


Public User 
Identity 


To: 


Identity which is used to 
communicate with other 
users 


Visited Network 
Identifier 


P-Visited- 
Network-ID: 


This information indicates 
the network identifier of the 
visited network 



28. REGISTER request (I-CSCF to S-CSCF) - see example in table 6.9.3-28 

This signalling flow forwards the REGISTER request from the l-CSCF to the S-CSCF selected. 

Table 6.9.3-28: REGISTER request (l-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p.homel . net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
Path: 
Require : 

P-Visited-Network-ID : 
P-Charging-Vector : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
CSeq: 

Supported: 
Expires : 
Content-Length : 



Path: 



The S-CSCF stores the contents of the Path header and uses this URI for routeing mobile 
terminated sessions. 



29. Authentication 

Upon receiving the REGISTER request carrying the authentication response, RES, the S-CSCF checks that 
the user's active, XRES matches the received RES. If the check is unsuccessful, and no more authentication 
challenges are to be made, then the authentication has failed and the public user identity is not registered in 
the S-CSCF. 

30. Cx: S-CSCF registration notification procedure 

Upon user authentication failure the S-CSCF informs the HSS that the user has not been registered at this 
instance. The HSS clears the S-CSCF name for that subscriber. 

For detailed message flows see 3GPP TS 29.229. 

Table 6.9.3-30 provides the parameters in the REGISTER request (flow 18) which needs to be sent to HSS. 

Table 6.9.3-30 Cx: S-CSCF registration notification procedure (S-CSCF to HSS) 
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Message 

source & 

destination 


Cx Information 
element name 


Information 

Source in 

REGISTER 

request 


Description 


S-CSCF to HSS 


Public User 
Identify 


To: 


Identity which is used to 
communicate with other 
users 


Private User 
Identity 


Authorization: 


The Private User Identity is 
encoded in the username 
field according to the 
Authorization protocol. 


S-CSCF name 


Request-URI: 


This information indicates 
the serving CSCF's name of 
that user 



31. 403 (Forbidden) response (S-CSCF to I-CSCF) - see example in table 6.9.3-31 

The S-CSCF sends an 403 (Forbidden) response to the I-CSCF indicating that authentication failed. No 
security parameters are included in this response. The S-CSCF will insert a warning header in the response, 
indicating to the UE the reason of refusing the Registration request. The Warning header will contain the 
name of the network inserting the warning header (warn-agent = homel.net) and in addition it may contain a 
warn-text.The warn-code inserted into the Warning header is 399. 

Table 6.9.3-31 : 403 (Forbidden) response (S-CSCF to I-CSCF) 

SIP/2.0 403 Forbidden 

Via: SIP/2. 0/UDP icscf l_p . homel . net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Warning; 399 homel.net "Authentication failed" 
From; <sip ; userl_publicl@homel .net>;tag=4fa3 
To; <sip;userl_publicl@homel . net>; tag=5ef4 
Call- ID; apb03a0s0 9dkjdfglkj4 9111 
CSeq; 3 REGISTER 
Content-Length; 

32. 403 (Forbidden) response (I-CSCF to P-CSCF) - see example in table 6.9.3-32 

The 1-CSCF forwards the 403 (Forbidden) response from the S-CSCF to the P-CSCF indicating that 
authentication was unsuccessful. 

Table 6.9.3-32: 403 (Forbidden) response (I-CSCF to P-CSCF) 

SIP/2.0 403 Forbidden 

Via; SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Warning; 399 homel.net "Authentication failed" 

From; 
To; 

Call-ID; 
CSeq; 
Content-Length ; 

33. 403 (Forbidden) response (P-CSCF to UE) - see example in table 6.9.3-33 

The P-CSCF forwards the 403 (Forbidden) response to the UE. 

Table 6.9.3-33: 403 (Forbidden) response (P-CSCF to UE) 

SIP/2.0 403 Forbidden 

Via; SIP/2. 0/UDP [5555 ;; aaa;bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 

Warning; 399 homel.net "Authentication failed" 

From; 

To; 

Call-ID; 

CSeq; 

Content-Length ; 
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34. PDF Context Deactivate 

On receiving the 403 (Forbidden) response the UE ceases registration and authentication attempts. In this 
case, if the PDP context on which the SIP signalling was being conducted is not being used for other 
purposes, the UE deactivates the signalling PDP context. 



7 Signalling flows for session initiation (non hiding) 

7.1 Introduction 

This subclause breaks down the signalling flows for establishing sessions into a number of individual procedures, 
following the same principles as 3GPP TS 23.228 [2] subclause 5.4.9. 

For the purposes of this document, a further breakdown has been necessary, and therefore a number of signalling flows 
have been given an (a) or (b) suffix, so that the signalling flows for establishing sessions where configuration 
independence is applied may be distinguished from those where it is not, e.g.: 

(MO#la) Mobile origination, roaming, without I-CSCF providing configuration independence. 

(MO#lb) Mobile origination, roaming, with I-CSCF in home network providing configuration independence. 



7.2 Origination procedures 



7.2.1 IntrocJuction 

This subclause presents the detailed signalling flows to define the procedures for session originations. 

The session origination procedures specify the signalling path between the UE initiating a session attempt and the S- 
CSCF that is assigned to perform the session origination service. This signalling path is determined at the time of UE 
registration, and remains fixed for the life of the registration. 

A UE always has a proxy (P-CSCF) associated with it. This P-CSCF is located in the same network as the UE, performs 
resource authorization, and may have additional functions in handling of emergency sessions. The P-CSCF is 
determined by the CSCF discovery process. 

As a result of the registration procedure, the P-CSCF determines the next hop toward the S-CSCF. This next hop may 
be directly to the S-CSCF (MO#la for the roaming case, MO#2 for the home case), or to an I-CSCF who forwards the 
request to the S-CSCF (MO#lb). These next-hop addresses could be IPv6 addresses, or could be names that are 
translated via DNS to an IPv6 address. 

Sessions originated in the PSTN to a mobile destination are a special case of the Origination procedures and three 
possibilities to route such sessions are detailed. In the first one, all sessions originated in the PSTN are routed towards 
the IM CN subsystem. The MGCF uses H.248/MEGACO to control a Media Gateway, and communicates with the SS7 
network. In case of interworking between IP based and SS7 based signalling network is required, a SGW would be used 
[2]. The MGCF initiates the SIP request, and subsequent nodes consider the signalling as if it came from a S-CSCF. In 
the second one, all sessions originated in the PSTN are routed towards the CS domain. The entry point of the network is 
then a G-MSC. In the third one, the operator can choose to handle simultaneously the first two routing possibilities and 
a way to handle this flexibility is detailed. 
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7.2.2 M0#1a 

7.2.2.1 (M0#1 a) Mobile origination, roaming (S-S#1 a, MT#1 a assumed) 

Figure 7.2.2.1-1 shows an origination procedure which applies to roaming subscribers when the home network operator 
does not desire to keep its internal configuration hidden from the visited network. The UE is located in a visited 
network, and determines the P-CSCF via the CSCF discovery procedure. During registration, the home network 
allocates a S-CSCF. The home network provides the S-CSCF name/address as the entry point from the visited network. 

When registration is complete, P-CSCF knows the name/address of the S-CSCF. 
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Visited Network 



Home Network 



UE#1 



P-CSCF 



1. INVITE 



-2. 100 Trying 



S-CSCF 



-3. INVITE- 



-4. 100 Trying- 



5. Evaluation of Initial 
Filter Criterias 
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Figure 7.2.2.1-1: M0#1a 

Procedure MO#la is as follows: 

1. INVITE (UE to P-CSCF) - see example in table 7.2.2.1-1 
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UE#1 determines the complete set of codecs that it is capable of supporting for this session. It builds a SDP 
containing bandwidth requirements and characteristics of each, and assigns local port numbers for each 
possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there 
may be multiple codec choices offered. 

For this example, assume UE#1 is capable of sending two simultaneous video streams, either H261 or MPV 
format, and two simultaneous audio streams, either AMR, G726-32, PCMU, or G728. 

UE sends the INVITE request, containing an initial SDP, to the P-CSCF determined via the CSCF discovery 
mechanism. The initial SDP may represent one or more media for a multimedia session. 

Table 7.2.2.1-1 : INVITE (UE to P-CSCF) 

INVITE tel:+I-2I2-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Pref erred-Identity ; "John Doe" <sip;userl_publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From; <sip ; userl_publicl@homel . net>; tag=I71828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: <sip: [5555: : aaa:bbb: ccc: ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 00 RTP/AVP 98 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H2 61 

a=rtpmap: 99: MPV 

m=video 3402 RTP/AVP 98 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H2 61 

a=rtpmap: 99: MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Request-URI: contains the keyed number from the user. 

Via: contains the IP address or FQDN of the originating UE. 
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Privacy: the user does not require privacy, therefore the Privacy header is set to the value "none" as 

specified in draft-ietf-sip-asserted-identity [17] and draft-ietf-sip-privacy-general [13]. 

P-Preferred-Identity: the user provides a hint about the identity to be used for this session. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 

24.229 [16]. 

From: the user does not require privacy, the From header contains the value requested by the user. 

Cseq: is a random starting number. 

Contact: is a SIP URL that contains the IP address or FQDN of the originating UE. 

SDP The SDP contains a set of codecs supported by UE#1 and desired by the user at UE#1 for this 

session. 

Upon receiving the INVITE, the P-CSCF stores the following information about this session, for use in 
possible error recovery actions - see example in table 7.2.2.1 -lb. 

Table 7.2.2.1 -lb: Storage of information at P-CSCF 



Requ 


est-URI 


tel:+l- 


-212-555 


-2222 








From 


; <sip ; userl_publicl@homel 


net> 


; t 


ag= 


=171828 1 


To: 


<tel:+l- 


212-555- 


-2222> 












Call 


-ID: cb03a0s09a2sdfglkj 


490333 








Cseq 


(2dest) 


127 INVITE 












Cseq 


(2orig) 


none 














Cont 


act (orig) : <sip 


[5555: : 


aaa 


bbb: 


ccc 


:ddd]> i 



2. 100 Trying (P-CSCF to UE) - see example in table 7.2.2.1-2 

P-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.2.2.1-2: 100 Trying (P-CSCF to UE) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. INVITE (P-CSCF to S-CSCF) - see example in table 7.2.2.1-3 

P-CSCF remembers (from the registration procedure) the request routing for this UE. This becomes a Route 
header in the request. This next hop is the S-CSCF within the home network of UE#1. 

P-CSCF adds itself to the Record-Route header and Via header. 

P-CSCF examines the media parameters, and removes any choices that the network operator decides based 
on local policy, not to allow on the network. 

For this example, assume the network operator disallows H261 video encoding. 

The INVITE request is forwarded to the S-CSCF. 

Table 7.2.2.1-3: INVITE (P-CSCF to S-CSCF) 

INVITE tel:-H-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr> 
Record-Route : <sip:pcscfl. visitedl. net;lr> 
P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 
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P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

Privacy : 

From; 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 00 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video 3402 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Route: contains the elements from the Path header from registration. 

P-Asserted-Identity: P-CSCF inserts the SIP URI in the P-Asserted-Identity header field and it also removes P- 
Preferred-Identity header field. 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the video media streams no longer list code 98 (H261). 

Upon receiving the INVITE, the S-CSCF stores the following information about this session, for use in 
charging or possible error recovery actions - see example in table 7.2.2.1 -3b. 

Table 7.2.2.1 -3b: Storage of information at S-CSCF 

I Request-URI: tel : +1-212-555-2222 

; From: <sip : userl_publicl@homel . net>; tag=171828 

: To: <tel:+l-212-555-2222> 
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Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq(2dest): 127 INVITE 

Cseq(2orig) : none 

Route(2orig) ; <sip ; pcscf 1 . visitedl . net ; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

Contact (orig) : <sip: [5555: : aaa:bbb: ccc: ddd] > 



4. 100 Trying (S-CSCF to P-CSCF) - see example in table 7.2.2.1-4 

S-CSCF responds to the INVITE request (3) with a 100 Trying provisional response. 

Table 7.2.2.1-4: 100 Trying (S-CSCF to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 

CSeq: 
Content-Length: 

5. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

6. INVITE (MO#l to S-S) - see example in table 7.2.2.1-6 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 

S-CSCF forwards the INVITE request, as specified by the S-CSCF to S-CSCF procedures. 
Table 7.2.2.1-6: INVITE request (M0#1a to S-S) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branc]i=z9]iG4bKnas]ids7 
Max-Forwards: 68 

Route: <sip: scscf 2 .]iome2 . net; lr> 

Record-Route : <sip:scscfl. liomel .net;lr>, <s ip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "Jolin Doe" <sip : userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Cliarging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=]iomel . net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Lengtli : (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 
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a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



SDP 



The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 
the video media streams show a port number zero, which removes them from the negotiation. 



P-Asserted-Identity: The S-CSCF inserts the corresponding TEL URL to the P-Asserted-Identity header in order 
that the TEL URL is known to the destination network in case the INVITE is forwarded to a 
MGCF. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 

Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP-URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

7. 100 Trying (S-S to MO#la) - see example in table 7.2.2.1-7 (related to table 7.2.2.1-6) 

S-CSCF receives a 100 Trying provisional response, as specified by the S-CSCF to S-CSCF procedures. 

Table 7.2.2.1-7: 100 Trying (S-S to M0#1a) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

8. 183 Session Progress (S-S to MO#la) - see example in table 7.2.2.1-8 (related to table 7.2.2.1-6) 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response (to 6), per the S-CSCF to S-CSCF procedures. 

Table 7.2.2.1-8: 183 Session Progress (S-S to M0#1a) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr>, 
<sip:pcscfl .visitedl . net; lr> 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
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Privacy; none 

From; 

To; <tel;+l-212-555-2222>; tag=314159 

Call-ID; 

CSeq; 

Require; lOOrel 

Contact; <sip;[5555; 

RSeq; 9021 

Content-Type; application/sdp 

Content-Length; (...) 



; eee ; f f f ; aaa;bbb] > 



IN IP6 5555; 
eee ; f f f ; aaa ; bbb 



96 



v=0 

o=- 2987933615 2987933615 

s=- 

c=IN IP6 5555 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes 

a=rtpmap;96 G726-32/8000 

m=audio RTP/AVP 97 96 15 



; aaa ; bbb ; c c c ; ddd 



Upon receiving the 183 Session Progress, the S-CSCF stores the following information about this session, for 
use in providing enhanced services, charging or in possible error recovery actions - see example in table 
7.2.2.1-8b. 

Table 7.2.2.1 -8b: Storage of information at S-CSCF 



Request-URI ; sip ; user2_publicl@home2 .net 

From; <sip ; userl_publicl@homel . net>; tag=171828 

To; <tel;+l-212-555-2222> 

Call-ID; cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest) ; 127 INVITE 

CSeq(2orig) ; none 

Route (2dest ) ; <sip;scscf2. home 2 .net; lr>, <sip ;pcscf2 .visited2 .net; lr> 

Route (2orig) ; <sip ;pcscf 1 . visitedl . net ; lr> 

P-Charging-Vector ; icid-value=12 34bcd987 6e; icid-generated-at= [ 5555 ; ; f 5f ; 

ioi=homel .net; term-ioi=home2 .net 
Contact (dest); <sip;[5555; ;eee ; iff ; aaa ;bbb] > 
Contact (orig) ; <sip; [5555; ;aaa ;bbb : ccc: ddd] > 



;d3d; c2c] ; orig- 



9. 183 Session Progress (S-CSCF to P-CSCF) - see example in table 7.2.2.1-9 
S-CSCF forwards the 183 Session Progress response to P-CSCF. 

Table 7.2.2.1-9: 183 Session Progress (S-CSCF to P-CSCF) 

SIP/2.0 183 Session Progress 

Via; SIP/2. 0/UDP pcscfl . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route ; 
P -As sorted- Identity; 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
Privacy ; 
From; 
To; 

Call-ID; 
CSeq; 
Require ; 
Contact ; 
RSeq; 

Content-Type ; 
Content-Length ; 
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Upon receiving the 183 Session Progress, the P-CSCF removes the Record-Route headers, calculates the 
proper Route header to add to future requests, and saves that information without passing it to UE. The saved 
value of the information for this session is - see example in table 7.2.2. l-9b. 

Table 7.2.2.1 -9b: Storage of information at P-CSCF 

Request-URI: tel : +1-212-555-2222 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call-ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq(2dest) : 127 INVITE 

CSeq(2orig): none 

Route(2dest) : <sip : scscf 1 .homel .net; lr>, <sip : scscf 2 .home2 .net; lr>, 

<sip:pcscf2 .visited2 . net; lr> 
P-Charging-Vector : icid-value=12 34bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] 
Contact (dest ) : <sip: [5555: :eee:fff:aaa :bbb] > 
I Contact (orig) : <sip: [5555: :aaa :bbb : ccc :ddd] > 

10. Authorize QoS Resources 

P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens 
at this stage or after 200 OK of INVITE (35) based on operator local policy. 

1 1. 183 Session Progress (P-CSCF to UE) - see example in table 7.2.2.1-11 

P-CSCF forwards the 183 Session Progress response to the originating endpoint. 

Table 7.2.2.1-11: 183 Session Progress (P-CSCF to UE) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Asserted- Identity: 

Privacy : 

P-Media- 

Authorizat ion: 0020000 100 100 10 170 64 66322e7 66973 6974 65 64322e6e6574 00 0c02 013 9425633303732 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



o= 
s= 
c= 

t= 

m= 
m= 
m= 
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b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 



P-Media-Authorization: a P-CSCF generated authorization token. This particular example shows a Policy-Element 
generated by "pdf2.visited2.net" with credentials "9BV3072". "00" at the end of the 
authorization token is required to pad to a multiple of 4 bytes. 

12. PRACK (UE to P-CSCF) - see example in table 7.2.2.1-12 

UE#1 determines which media flows should be used for this session, and which codecs should be used for 
each of those media flows. If there was any change in media flows, or if there was more than one choice of 
codec for a media flow, then UE#1 includes a new SDP offer in the PRACK message sent to UE#2. 

For this example, assume UE#1 chooses AMR as the codec to use for the single audio stream. 

UE includes this information in the PRACK request to P-CSCF. 



Table 7.2.2.1-12: PRACK (UE to P-CSCF) 



PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 128 PRACK 

Require: precondition 

Rack: 9021 127 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



Request-URI: takes the value of the Contact header of the received 183 Session Progress response. 

Via: takes the value of either the IP address or FQDN of the originating UE. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 
24.229 [16]. 

From:/To:/Call-ID: copied from the 183 Session Progress response so that they include any tag parameter. 

Cseq: takes a higher value than that in the previous request. 

13. Resource Reservation 
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After determining the final media streams in step #1 1, UE initiates the reservation procedures for the 
resources needed for this session. 

14. PRACK (P-CSCF to S-CSCF) - see example in table 7.2.2.1-14 

P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the PRACK request to S-CSCF. 

Table 7.2.2.1-14: PRACK (P-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Route: saved from the Record-Route header of the 183 Session Progress response. 

15. PRACK (MO#la to S-S) - see example in table 7.2.2.1-15 

S-CSCF forwards the PRACK request to the terminating endpoint, as per the S-CSCF to S-CSCF procedure. 

Table 7.2.2.1-15: PRACK (M0#1a to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 
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16. 200 OK (S-S to MO#la) - see example in table 7.2.2.1-16 (related to table 7.2.2.1-15) 

The destination endpoint responds to the PRACK request (14) with a 200 OK response, per the S-CSCF to S- 
CSCF procedures. 

Table 7.2.2.1-16: 200 OK (S-S to M0#1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; : aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



17. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.2.1-17 

S-CSCF forwards the 200 OK response to P-CSCF. 

Table 7.2.2.1-17: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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18. 200 OK (P-CSCF to UE) - see example in table 7.2.2.1-18 

P-CSCF forwards the 200 OK response to UE. 

Table 7.2.2.1-18: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



19. UPDATE (UE to P-CSCF) - see example in table 7.2.2.1-19 

When the resource reservation is completed, UE sends the UPDATE request to the terminating endpoint, via 
the signalling path established by the INVITE request. 

Table 7.2.2.1-19: UPDATE (UE to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 129 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 
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a=des:qos mandatory remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 
m=audio RTP/AVP 97 96 15 



Request-URI: takes the value of the Contact header of the received 183 Session Progress response. 

Via: takes the value of either the IP address or FQDN of the originating UE. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 
24.229 [16]. 

Froin:/To:/Call-ID: copied from the 183 Session Progress response so that they include any tag parameters. 

Cseq: takes a higher value than that in the previous request. 

The SDP indicates that the resource reservation was successful in the local segment. 
20. UPDATE (P-CSCF to S-CSCF) - see example in table 7.2.2.1-20 

P-CSCF adds the Route header corresponding to the session. 

P-CSCF forwards the UPDATE request to S-CSCF. 

Table 7.2.2.1-20: UPDATE (P-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : icid-value=1234bcd987 6e; ic id-gene rat ed-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3 
Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf2 .home2 . net; lr>, <sip:pcscf2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



Route: 



saved from the Record-Route header of the 183 Session Progress response. 



P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

P-Charging- Vector: The P-CSCF added the GPRS access network information to this header, which is removed 
and stored by the S-CSCF. 

Upon receiving the UPDATE, the S-CSCF stores the following information about this session, for use in 
charging - see example in table 7.2.2.1 -20b. 
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Table 7.2.2. 1-20b: Storage of information at S-CSCF 



Request-URI: tel : +1-212-555-2222 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq(2dest) : 127 INVITE 

Cseq(2orig) : none 

Route {2orig) : <sip:pcscf 1 . visitedl . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net ; term-ioi=home2 . net ; ggsn= [5555 :: 4b4 : 3c3 : 2d2 : lei] ; pdp-sig=no; gcid=723084371; 

auth-token=43876559; flow-id=3 
Contact (orig) : <sip: [5555: : aaa:bbb: ccc: ddd] > 



21. UPDATE (MO#la to S-S) - see example in table 7.2.2.1-21 

S-CSCF forwards the UPDATE request to the terminating endpoint, as per the S-CSCF to S-CSCF 
procedure. 

Table 7.2.2.1-21 : UPDATE (M0#1a to S-S) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branc]i=z9]iG4bKnas]ids7 
Max-Forwards: 68 

Route: <sip: scscf 2 .]iome2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Lengtli : 



22. 200 OK (S-S to MO#la) - see example in table 7.2.2.1-22 (related to table 7.2.2.1-21) 

The destination endpoint responds to the UPDATE request (21) with a 200 OK, per the S-CSCF to S-CSCF 
procedures. 

Table 7.2.2.1-22: 200 OK (S-S to IVI0#1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . liomel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .visitedl . net; brancli=z91iG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branc]i=z9]iG4bKnas]ids7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Lengtli: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
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c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr;qos local sendrecv 

a=curr;qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



The SDP indicates that the resource reservation was successful both in the local and the remote segment. 
23. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.2.1-23 
S-CSCF forwards the 200 OK response to P-CSCF. 

Table 7.2.2.1-23: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



24. 200 OK (P-CSCF to UE) - see example in table 7.2.2.1-24 

P-CSCF forwards the 200 OK response to UE. 

Table 7.2.2.1-24: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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25. 180 Ringing (S-S to MO#la) - see example in table 7.2.2.1-25 (related to table 7.2.2.1-6) 

The called UE may optionally perform alerting. If so, it signals this to the calling party by a 180 Ringing 
provisional response to (6). This response is sent to S-CSCF per the S-CSCF to S-CSCF procedure. 

Table 7.2.2.1-25: 180 Ringing (S-S to M0#1a) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route : <sip;pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net;lr>, <sip;scscfl. homel .net; lr>, 
<sip:pcscfl .visitedl . net; lr> 
From: 

To: <tel:+l-212-555-2222>; tag=314159 
Call-ID: 
CSeq: 

Require: lOOrel 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 
RSeq: 9022 
Content-Length: 



26. 180 Ringing (S-CSCF to P-CSCF) - see example in table 7,2,2,1-26 

S-CSCF forwards the 180 Ringing response to P-CSCF. 

Table 7.2.2.1-26: 180 Ringing (S-CSCF to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscfl .visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

27. 180 Ringing (P-CSCF to UE) - see example in table 7.1.1-27 
P-CSCF removes the Record-Route headers. 
P-CSCF forwards the 180 Ringing response to UE. 

Table 7.2.2.1-27: 180 Ringing (P-CSCF to UE) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 
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28. PRACK (UE to P-CSCF) - see example in table 7.2.2.1-28 



UE indicates to the originating subscriber that the destination is ringing. It responds to the 180 Ringing 
provisional response (28) with a PRACK request. 

Table 7.2.2.1-28: PRACK (UE to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 PRACK 

Rack: 9022 127 INVITE 

Content-Length: 

Request-URI: takes the value of the Contact header of the received 180 Ringing response. 

Via: takes the value of either the IP address or FQDN of the originating UE. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 

24.229 [16]. 

From:/To:/Call-ID: copied from the 180 Ringing response so that they include any revised tag parameters. 
Cseq: takes a higher value than in the previous request. 

29. PRACK (P-CSCF to S-CSCF) - see example in table 7.2.2.1-29 

P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the PRACK request to S-CSCF. 

Table 7.2.2.1-29: PRACK (P-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

30. PRACK (MO#la to S-S) - see example in table 7.2.2.1-30 

S-CSCF forwards the PRACK request to the terminating endpoint, as per the S-CSCF to S-CSCF procedure. 

Table 7.2.2.1-30: PRACK (M0#1a to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
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To: 

Call-ID: 
Cseq: 
Rack: 

Content-Length : 



31. 200 OK (S-S to MO#la) - see example in table 7.2.2.1-31 (related to table 7.2.2.1-30) 

The destination endpoint responds to the PRACK request (30) with a 200 OK response. 

Table 7.2.2.1-31 : 200 OK (S-S to M0#1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

32. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.2.1-32 
S-CSCF forwards the 200 OK response to P-CSCF. 

Table 7.2.2.1-32: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

33. 200 OK (P-CSCF to UE) - see example in table 7.2.2.1-33 

P-CSCF forwards the 200 OK response to UE. 

Table 7.2.2.1-33: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

34. 200 OK (S-S to MO#la) - see example in table 7.2.2.1-34 (related to table 7.2.2.1-6) 

When the called party answers, the terminating endpoint sends a 200 OK final response to the INVITE 
request (6), as specified by the termination procedures and the S-CSCF to S-CSCF procedures, to S-CSCF. 



Table 7.2.2.1-34: 200 OK (S-S to M0#1a) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr>, 
<sip:pcscf 1 .visitedl . net; lr> 
From: 

To: <tel:+l-212-555-2222>; tag=314159 
Call-ID: 

CSeq: 127 INVITE 
Contact: <sip: [5555: : eee : f f f : aaa : bbb] > 
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Content-Length : 

35. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.2.1-35 

S-CSCF sends a 200 OK final response along the signalling path back to P-CSCF. 

Table 7.2.2.1-35: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa ; bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From; 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

36. Approval of QoS Commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (10). 

37. 200 OK (P-CSCF to UE) - see example in table 7.2.2.1-37 

P-CSCF forwards the 200 OK final response to the session originator. UE can start the media flow(s) for this 
session. 

Table 7.2.2.1-37: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

38. ACK (UE to P-CSCF) - see example in table 7,2,2,1-38 

UE starts the media flow for this session, and responds to the 200 OK (37) with an ACK request sent to P- 
CSCF. 

Table 7.2.2.1-38: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Networli-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: cb03a0s0 9a2sdf gilt j 4 90333 

Cseq: 127 ACK 

Content-Length: 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 
24.229 [16]. 

Cseq: is required to be the same value as Cseq contained in original INVITE request [3]. 

39. ACK (P-CSCF to S-CSCF) - see example in table 7.2.2.1-39 

P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the ACK request to S-CSCF. 
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Table 7.2.2.1-39: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf2 .home2 . net; lr>, <sip:pcscf2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Route: saved from the Record-Route header of the 183 Session Progress response. 

40. ACK (MO#la to S-S) - see example in table 7.2.2.1-40 

S-CSCF forwards the ACK request to the terminating endpoint, per the S-CSCF to S-CSCF procedure. 

Table 7.2.2.1-40: ACK (M0#1a to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

7.2.2.2 Failure in termination procedure 

The roaming subscriber that initiated a session with procedure MO#la had the attempt fail due to an error detected in 
the Termination procedure or in the S-CSCF-to-S-CSCF procedure. This could be due to, for example, destination busy 
(error code 486), destination service denied (error code 403), destination currently out of coverage (error code 480), or 
some other error. 

Depending on the exact error that causes the session initiation failure, and when the error situation was detected, UE#1 
could be at many different stages in the session establishment procedure. This is shown in figure 7.2.2.2-1, as optional 
messages 7-33 that may appear in this error procedure. 
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Figure 7.2.2.2-1 : Failure in termination procedure 
1-6. INVITE (UE to P-CSCF) et seq 
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UE#1 initiated a session, as described in subclause 7.2.2.1. 

7-33.100 Trying (S-S to MO#la) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.2.2.1. 

34. XXX Error (S-S to MO#la) - see example in table 7.2.2.2-34 

The termination procedure detected some error situation, and returned a SIP error response. 

NOTE 1 : The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 

Table 7.2.2.2-34: 486 Busy Here (S-S to M0#1a) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>; tag=314159 
Call-ID: 

CSeq: 127 INVITE 
Retry-After: 3600 
Content-Length: 

35. ACK (MO#la to S-S) - see example in table 7.2.2.2-35 

Upon receive the 486 response from the S-S procedure, S-CSCF sends ACK. 

Table 7.2.2.2-35: ACK (M0#1a to S-S) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 
Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1 
From: 
To: 

Call-ID: 
CSeq: 127 ACK 
Content-Length: 

36. XXX Error (S-CSCF to P-CSCF) - see example in table 7.2.2.2-36 (related to table 7.2.2.2-34) 

The S-CSCF returned a SIP error response to P-CSCF. 

NOTE 2: The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 

Table 7.2.2.2-36: 486 Busy Here (S-CSCF to P-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

37. ACK (P-CSCF to S-CSCF) - see example in table 7.2.2.2-37 

Upon receive the 486 response from the S-CSCF procedure, P-CSCF sends ACK. 

Table 7.2.2.2-37: ACK (P-CSCF to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 
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Route : <sip:scscfl .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



38. Revoke QoS authorization 

P-CSCF removes the QoS authorization, if any, for this session. 

39. XXX Error (P-CSCF to UE) - see example in table 7.2.2.2-39 (related to table 7.2.2.2-36) 

The P-CSCF returned a SIP error response to UE. 

NOTE 3: The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 



Table 7.2.2.2-39: 486 Busy Here (P-CSCF to UE) 



SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 



40. ACK (P-CSCF to S-CSCF) - see example in table 7.2.2.2-40 

Upon receive the 486 response from the P-CSCF, UE sends ACK. 

Table 7.2.2.2-40: ACK (UE to P-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



7.2.2.3 



Session abandoned, or resource failure 



The roaming subscriber that initiated a session with procedure MO#la either abandoned the attempt, or was unable to 
obtain the resources necessary for the session. The signalling flow for this error handling is shown in figure 7.2.2.3-1. 

If the session is aborted due to failure to obtain resources, it will occur at step #18 in the signalling flow; steps 19-33 
(marked as optional) will not be present. If the session is abandoned due to user command, it can happen at any point 
between steps 8-33. 
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23. 200 OK 
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<45. 487 Request Term.- 
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W 8. 183 
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42. ACK ► 



Figure 7.2.2.3-1 : Session abandoned or resource failure 
1-7. INVITE (UE to P-CSCF) et seq 
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UE#1 initiated a session, as described in subclause 7.2.2.1. 

8-33.183 Session Progress (S-S to MO#la) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.2.2.1. 

34. CANCEL (UE to P-CSCF) - see example in table 7.2.2.3-34 

The UE cancelled the original INVITE request. 

Table 7.2.2.3-34: CANCEL (UE to P-CSCF) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 CANCEL 

Content-Length: 

35. 200 OK (P-CSCF to UE) - see example in table 7.2.2.3-35 

Upon receive the CANCEL request from the UE, P-CSCF sends 200 OK. 

Table 7.2.2.3-35: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

36. Revoke QoS authorization 

P-CSCF removes the QoS authorization, if any, for this session. 

37. CANCEL (P-CSCF to S-CSCF) - see example in table 7.2.2.3-37 

The P-CSCF forwards the CANCEL request to S-CSCF. 

Table 7.2.2.3-37: CANCEL (P-CSCF to S-CSCF) (related to table 7.2.2.3-34) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Route: <sip: scscf 1 .homel . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

38. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.2.3-38 

Upon receiving the CANCEL request from the P-CSCF, S-CSCF sends 200 OK. 

Table 7.2.2.3-38: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 
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39. CANCEL (S-CSCF to S-S) - see example in table 7.2.2.3-39 (related to table 7,2,2,3-37) 

The S-CSCF forwards the CANCEL request to the appropriate S-CSCF-to-S-CSCF procedure. 

Table 7.2.2.3-39: CANCEL (S-CSCF to S-S) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

40. 200 OK (S-S to S-CSCF) - see example in table 7.2.2.3-40 

Upon receive the CANCEL request from the S-CSCF, the next hop (whatever it is) sends 200 OK. 

Table 7.2.2.3-40: 200 OK (S-S to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

4L 487 Request Terminated (S-S to MO#la) - see example in table 7.2.2.3-41 

The termination procedure cancelled the request, and returned a SIP error response to the original INVITE 
request. 

Table 7.2.2.3-41 : 487 Request Terminated (S-S to M0#1a) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK24 Of 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 
Content-Length: 

42. ACK (MO#la to S-S) - see example in table 7.2.2.3-42 

Upon receive the 487 response from the S-S procedure, S-CSCF sends ACK. 

Table 7.2.2.3-42: ACK (M0#1a to S-S) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 
Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1 
From: 
To: 

Call-ID: 
CSeq: 127 ACK 
Content-Length: 

43. 487 Request Terminated (S-CSCF to P-CSCF) - see example in table 7.2.2.3-43 (related to table 7.2.2.3-41) 

The S-CSCF returned the SIP error response to P-CSCF. 
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Table 7.2.2.3-43: 487 Request Terminated (S-CSCF to P-CSCF) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc ; ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

44. ACK (P-CSCF to S-CSCF) - see example in table 7.2.2.3-44 

Upon receive the 487 response from the S-CSCF, P-CSCF sends ACK. 

Table 7.2.2.3-44: ACK (P-CSCF to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1 

Route: <sip: scscf 1 .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

45. 487 Request Terminated (P-CSCF to UE) - see example in table 7.2.2.3-45 (related to table 7.2.2.3-43) 
The P-CSCF returned a SIP error response to UE. 

Table 7.2.2.3-45: 487 Request Terminated (P-CSCF to UE) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

46. ACK (UE to P-CSCF) - see example in table 7.2.2.3-46 

Upon receive the 487 response from the P-CSCF, UE sends ACK. 

Table 7.2.2.3-46: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



7.2.3 M0#2 

7.2.3.1 (M0#2) Mobile origination, located in home network (S-S#2, MT#2 assumed) 

Figure 7.2.3.1-1 shows an origination procedure which apphes to subscribers located in their home service area. 

The UE is located in the home network, and determines the P-CSCF via the CSCF discovery procedure. During 
registration, the home network allocates an S-CSCF in the home network. 

When registration is complete, the P-CSCF knows the name/address of S-CSCF. 
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NOTE: Although S-S#2 flow is assumed, home2.net is used in the Record-Route and Route headers in order to be 
more generic and clearly identify the originating and terminating nodes. In the S-S#2 scenario home2.net 
= homel.net. 
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Figure 7.2.3.1-1 :M0#2 
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Procedure MO#2 is as follows: 

1. INVITE (UE to P-CSCF) - see example in table 7.2.3.1-1 

UE#1 determines the complete set of codecs that it is capable of supporting for this session. It builds a SDP 
containing bandwidth requirements and characteristics of each, and assigns local port numbers for each 
possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there 
may be multiple codec choices offered. 

For this example, assume UE#1 is capable of sending two simultaneous video streams, either H261 or MPV 
format, and two simultaneous audio streams, either AMR, G726-32, PCMU, or G728. 

UE sends the INVITE request, containing an initial SDP, to the P-CSCF determined via the CSCF discovery 
mechanism. 

Table 7.2.3.1-1 : INVITE (UE to P-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Preferred-Identity : "John Doe" <tel : +l-212-555-llll> 

Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 

To; <tel;+l-212-555-2222> 

Call- ID; Cb03a0s0 9a2sdfglkj4 90333 

Cseq; 127 INVITE 

Require; precondition 

Supported; lOOrel 

Contact; <sip; [5555; ; aaa;bbb; ccc ; ddd] > 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 3400 RTP/AVP 98 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;98 H2 61 

a=rtpmap; 99; MPV 

m=video 3402 RTP/AVP 98 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;98 H261 

a=rtpmap; 99; MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 
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Request-URI: Contains the keyed number from the user. This is specified by the UE as telxkeyed number>. 

This is in accordance to standard IETF procedures for specifying dialled digits. 

Via: contains the IP address or FQDN of the originating UE. 

P-Preferred-Identity:The user provides a hint about the identity to be used for this session. 

From:/To:/Call-ID: Follow the recommendations of draft-ietf-sip-privacy[13], even though anonymity is not being 
requested for this session. 

Cseq: A random starting number. 

Contact: is a SIP URL that contains the IP address or FQDN of the originating UE. 

SDP The SDP contains a set of codecs supported by UE#1 and desired by the user at UE#1 for this 

session. 

Upon receiving the INVITE, the P-CSCF stores the following information about this session, for use in 
possible error recovery actions - see example in table 7.2.3. 1-lb: 

Table 7.2.3.1 -1b: Storage of information at P-CSCF 



Request-URI : 


tel:+l- 


-212-555 


-2222 






From: <sip ; userl_publicl@homel . net> 


; tag=171828 


To: <tel:+l- 


212-555- 


-2222> 








Call-ID: cb03a0s09a2sdfglk] 


490333 






Cseq(2dest) : 


127 INVITE 








Cseq (2orig) : 


none 










Contact (orig 


) : <sip 


[5555: : 


aaa :bbb : 


ccc 


ddd]> 



2. 100 Trying (P-CSCF to UE) - see example in table 7.2.3.1-2 

P-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.2.3.1-2: 100 Trying (P-CSCF to UE) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. INVITE (P-CSCF to S-CSCF) - see example in table 7.2.3.1-3 

P-CSCF remembers (from the registration procedure) the request routing for this UE. This becomes a Route 
header in the request. This next hop is the S-CSCF within the home network of UE#1. 

P-CSCF adds itself to the Record-Route header and Via header. 

P-CSCF examines the media parameters, and removes any choices that the network operator decides based 
on local policy, not to allow on the network. 

For this example, assume the network operator disallows H261 video encoding. 

The INVITE request is forwarded to the S-CSCF. 

Table 7.2.3.1-3: INVITE (P-CSCF to S-CSCF) 

INVITE tel:-H-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Record-Route : <sip:pcscfl. homel .net; lr> 
Route: <sip: scscfl .homel . net; lr> 

P-Asserted-Identity: "John Doe" <tel : -H-212-555-llll> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
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Privacy : 

From; 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 00 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video 3402 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Route: Contains the elements from the Path header from registration. 

SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the video media streams no longer list code 98 (H261). 

P-Asserted-Identity: P-CSCF inserts the TEL URI in the P-Asserted-Identity header field and it also removes P- 
Preferred-Identity header field. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

Upon receiving the INVITE, the S-CSCF stores the following information about this session, for use in 
charging or possible error recovery actions - see example in table 7.2.3. 1 -3b: 

Table 7.2.3.1 -3b: Storage of information at S-CSCF 



i Request-URI: tel : +1-212-555-2222 

; From: <sip:userl_publicl@homel . net>; tag=171828 

! To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

Cseq(2orig) : none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e :d3d:c2c] 
■ Route (2orig) : <sip:pcscf 1 .homel . net; lr> 
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I Contact (orig) : <sip : [5555 : : aaa : bbb : ccc : ddd] > 

4. 100 Trying (S-CSCF to P-CSCF) - see example in table 7.2.3.1-4 

S-CSCF responds to the INVITE request (3) with a 100 Trying provisional response. 

Table 7.2.3.1-4: 100 Trying (S-CSCF to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

5. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

6. INVITE (MO#2 to S-S) - see example in table 7.2.3.1-6 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 

S-CSCF forwards the INVITE request, as specified by the S-CSCF to S-CSCF procedures. 

Table 7.2.3.1-6: INVITE (M0#2 to S-S) 

INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK431h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 
P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel . net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 
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a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the video media streams show a port number zero, which removes them from the negotiation. 

Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP-URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 

7. 100 Trying (S-S to MO#2) - see example in table 7.2.3.1-7 

S-CSCF receives a 100 Trying provisional response, as specified by the S-CSCF to S-CSCF procedures. 

Table 7.2.3.1-7: 100 Trying (S-S to M0#2) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

8. 183 Session Progress (S-S to MO#2) - see example in table 7.2.3.1-8 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response (to (6)), per the S-CSCF to S-CSCF procedures. 

Table 7.2.3.1-8: 183 Session Progress (S-S to M0#2) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : <sip:pcscf2. home 2 .net;lr>, <sip:scscf2. home 2 .net; lr>^ 
<sip:332b23. l@scscfl.homel.net; lr>, <sip:431h23. l@pcscfl.homel.net; lr> 
P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
Privacy: none 
From: 

To: <tel:+l-212-555-2222>; tag=314159 
Call-ID: 
CSeq: 

Require: lOOrel 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 
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o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 



Upon receiving the 183 Session Progress, the S-CSCF stores the following information about this session, for 
use in providing enhanced services, charging or in possible error recovery actions - see example in table 
7.2.3. l-8b. 

Table 7.2.3.1 -8b: Storage of information at S-CSCF 



Request-URI: tel : +1-212-555-2222 

From; <sip ; userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route {2dest) : <sip:scscf2. home 2 . net; lr>, <sip:pcscf2 . home 2 .net; lr> 

Route(2orig) : <sip : pcscf 1 . homel . net ; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

Contact (dest) : <sip: [5555: :eee:fff: aaa:bbb] > 

Contact (orig) : <sip: [5555: : aaa : bbb : ccc : ddd] > 



9. 183 Session Progress (S-CSCF to P-CSCF) - see example in table 7.2.3.1-9 

S-CSCF forwards the 183 Session Progress response to P-CSCF. 

Table 7.2.3.1-9: 183 Session Progress (S-CSCF to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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Upon receiving the 183 Session Progress, the P-CSCF removes the Record-Route headers, calculates the 
proper Route header to add to future requests, and saves that information without passing it to UE. The saved 
value of the information for this session is - see example in table 7.2.3. l-9b: 

Table 7.2.3.1 -9b: Storage of information at P-CSCF 



Request-URI: tel : +1-212-555-2222 

From; <sip ; userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route{2dest) : <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, 

<sip:pcscf2 . home 2 .net; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

Contact (dest): <sip: [5555 : : eee : f f f : aaa:bbb] > 

Contact (orig) : <sip: [5555 : : aaa:bbb: ccc: ddd] > 



10. Authorize QoS Resources 

P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens 
at this stage or after 200 OK of INVITE (35) based on operator local policy. 

1 1. 183 Session Progress (P-CSCF to UE) - see example in table 7.2.3.1-11 

P-CSCF forwards the 183 Session Progress response to the originating endpoint. 

Table 7.2.3.1-11: 183 Session Progress (P-CSCF to UE) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Media-Authorization: 0020000100100101706466312e686f 6d65312e6e6574000c02013942563330373200 

P -Asserted- Identity : 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 
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P-Media-Authorization: a P-CSCF generated authorization token. This particular example shows a Policy-Element 
generated by "pdfl.homel.net" with credentials "9BV3072". "00" at the end of the 
authorization token is required to pad to a multiple of 4 bytes. 

12. PRACK (UE to P-CSCF) - see example in table 7.2.3.1-12 

UE#1 determines which media flows should be used for this session, and which codecs should be used for 
each of those media flows. If there was any change in media flows, or if there was more than one choice of 
codec for a media flow, then UE#1 include a new SDP offer in the PRACK request sent to UE#2). 

For this example, assume UE#1 chooses AMR as the codec to use for the single audio stream. 

UE includes this information in the PRACK request to P-CSCF. 

Table 7.2.3.1-12: PRACK (UE to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 128 PRACK 

Require: precondition 

Rack: 9021 127 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

Request-URI: Takes the value of the Contact header of the received 183 Session Progress response. 

Via: Takes the value of either the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Copied from the 183 Session Progress response so that they include any tag parameter. 
Cseq: Takes a higher value than that in the previous request. 

13. Resource Reservation 

After determining the final media streams in step #1 1, UE initiates the reservation procedures for the 
resources needed for this session. 



14. PRACK (P-CSCF to S-CSCF) - see example in table 7.2.3.1-14 
P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the PRACK request to S-CSCF. 

Table 7.2.3.1-14: PRACK (P-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Max-Forwards: 69 

Route; <sip: scscf 1 .homel . net; lr>, <sip: scscf2 .home2 . net; lr>, <sip:pcscf2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



Request-URI: The first component of the saved Route header. 

Route: saved from the 183 Session Progress response (with first element moved to Request-URI) with 

the initial Request-URI (received from the UE) appended as the final component. 

15. PRACK (MO#2 to S-S) - see example in table 7.2,3,1-15 

S-CSCF forwards the PRACK request to the terminating endpoint, as per the S-CSCF to S-CSCF procedure. 

Table 7.2.3.1-15: PRACK (M0#2 to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c = 

t = 



16. 200 OK (S-S to MO#2) - see example in table 7.2.3.1-16 
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The destination endpoint responds to the PRACK request (14) with a 200 OK response, per the S-CSCF to S- 
CSCF procedures. 

Table 7.2.3.1-16: 200 OK (S-S to M0#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

17. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.3.1-17 
S-CSCF forwards the 200 OK response to P-CSCF. 

Table 7.2.3.1-17: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl .homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



18. 200 OK (P-CSCF to UE) - see example in table 7.2.3.1-18 

P-CSCF forwards the 200 OK response to UE. 
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Table 7.2.3.1-18: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 

c= 

t = 



19. UPDATE (UE to P-CSCF) - see example in table 7.2.3.1-19 

When the resource reservation is completed, UE sends the UPDATE request to the terminating endpoint, via 
the signalling path established by the INVITE request. The request is sent first to P-CSCF. 

Table 7.2.3.1-19: UPDATE (UE to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 129 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

Request-URI: Takes the value of the Contact header of the received 183 Session Progress response. 

Via: Takes the value of either the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Copied from the 183 Session Progress response so that they include any tag parameters. 
CSeq: Takes a higher value than that in the previous request. 

The SDP indicates that the resource reservation was successful in the local segment. 
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20. UPDATE (P-CSCF to S-CSCF) - see example in table 7.2.3.1-20 
P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the UPDATE request to S-CSCF. 

Table 7.2.3.1-20: UPDATE (P-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3 
Route: <sip: scscfl .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c = 

t = 



Route: saved from the Record-Route header of the 183 Session Progress response. 

Upon receiving the UPDATE, the S-CSCF stores the following information about this session, for use in 
charging - see example in table 7.2.3. l-20b. 

Table 7.2.3. 1-20b: Storage of information at S-CSCF 



Request-URI: tel : +1-212-555-2222 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq(2dest): 127 INVITE 

Cseq(2orig) : none 

Route (2orig) : <sip : pcscf 1 . visitedl . net> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net ; term-ioi=home2 . net; ggsn= [5555 :: 4b4 : 3c3 : 2d2 : lei] ; pdp-sig=no; gcid=723084371; 

auth-token=43876559; flow-id=3 
Contact (orig): <sip:[5555:: aaa: bbb: ccc: ddd] > 



21. UPDATE (MO#2 to S-S) - see example in table 7.2.3.1-21 

S-CSCF forwards the UPDATE request to the terminating endpoint, as per the S-CSCF to S-CSCF 
procedure. 

Table 7.2.3.1-21 : UPDATE (M0#2 to S-S) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
Route: <sip : scscf 2 . home2 . net ; lr>, <sip : pcscf 2 . home2 . net ; lr> 
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From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



22. 200 OK (S-S to MO#2) - see example in table 7.2.3.1-22 

The destination endpoint responds to the UPDATE request (21) with a 200 OK, per the S-CSCF to S-CSCF 
procedures. 

Table 7.2.3.1-22: 200 OK (S-S to M0#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

The SDP indicates that the resource reservation was successful both in the local and the remote segment. 
23. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.3.1-23 
S-CSCF forwards the 200 OK response to P-CSCF. 

Table 7.2.3.1-23: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
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CSeq: 

Content-Type : 
Content-Length ; 



24. 200 OK (P-CSCF to UE) - see example in table 7.2.3.1-24 

P-CSCF forwards the 200 OK response to UE. 

Table 7.2.3.1-24: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



25. 180 Ringing (S-S to MO#2) - see example in table 7.2.3.1-25 

The called UE may optionally perform alerting. If so, it signals this to the calling party by a 180 Ringing 
provisional response to (6). This response is sent to S-CSCF per the S-CSCF to S-CSCF procedure. 

Table 7.2.3.1-25: 180 Ringing (S-S to M0#2) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route: <sip:pcscf 2 .home2 . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip : scscf 1 . homel . net ; lr>, 
<sip:pcscfl . homel .net; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Require: lOOrel 
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Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 
RSeq: 9022 
Content-Length: 



26. 180 Ringing (S-CSCF to P-CSCF) - see example in table 7.2.3.1-26 

S-CSCF forwards the 180 Ringing response to P-CSCF. 

Table 7.2.3.1-26: 180 Ringing (S-CSCF to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

27. 180 Ringing (P-CSCF to UE) - see example in table 7.2.3.1-27 
P-CSCF removes the Record-Route headers. 
P-CSCF forwards the 180 Ringing response to UE. 

Table 7.2.3.1-27: 180 Ringing (P-CSCF to UE) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

28. PRACK (UE to P-CSCF) - see example in table 7.2.3.1-28 



UE indicates to the originating subscriber that the destination is ringing. It acknowledges the 180 Ringing 
provisional response (27) with a PRACK request. 

Table 7.2.3.1-28: PRACK (UE to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 PRACK 

Rack: 9022 127 INVITE 

Content-Length: 

Request-URI: Takes the value of the Contact header of the received 180 Ringing response. 

Via: Takes the value of either the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Copied from the 180 Ringing response so that they include any revised tag parameters. 
Cseq: Takes a higher value than in the previous request. 

29. PRACK (P-CSCF to S-CSCF) - see example in table 7.2.3.1-29 
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P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the PRACK request to S-CSCF. 

Table 7.2.3.1-29: PRACK (P-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Route: <sip: scscfl .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

30. PRACK (MO#2 to S-S) - see example in table 7.2.3.1-30 

S-CSCF forwards the PRACK request to the terminating endpoint, as per the S-CSCF to S-CSCF procedure. 

Table 7.2.3.1-30: PRACK (M0#2 to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

31. 200 OK (S-S to MO#2) - see example in table 7.2.3.1-31 

The destination endpoint responds to the PRACK request (30) with a 200 OK response. 

Table 7.2.3.1-31 : 200 OK (S-S to M0#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

32. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.3.1-32 
S-CSCF forwards the 200 OK response to P-CSCF. 

Table 7.2.3.1-32: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

33. 200 OK (P-CSCF to UE) - see example in table 7.2.3.1-33 
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P-CSCF forwards the 200 OK response to UE. 

Table 7.2.3.1-33: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length : 

34. 200 OK (S-S to MO#2) - see example in table 7.2.3.1-34 

When the called party answers, the terminating endpoint sends a 200 OK final response to the INVITE 
request (6), as specified by the termination procedures and the S-CSCF to S-CSCF procedures, to S-CSCF. 

Table 7.2.3.1-34: 200 OK (S-S to M0#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc: ddd] ;branch=z9hG4bKnashds7 

Record-Route: <sip:pcscf2 .home2 . net; lr>, <sip: scscf2 .home2 . net; lr>, <sip: scscf 1 .homel . net; lr>, 

<sip:pcscfl . homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

Content-Length: 

35. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.3.1-35 

S-CSCF sends a 200 OK final response along the signalling path back to P-CSCF. 

Table 7.2.3.1-35: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

36. Approval of QoS Commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (10). 

37. 200 OK (P-CSCF to UE) - see example in table 7.2.3.1-37 

P-CSCF indicates the resources reserved for this session should now be committed, and forwards the 200 OK 
final response to the session originator. UE can start media flow(s) for this session. 

Table 7.2.3.1-37: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 119 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

38. ACK (UE to P-CSCF) - see example in table 7.2.3.1-38 

UE starts the media flow for this session, and responds to the 200 OK (39) with an ACK request sent to P- 
CSCF. 

Table 7.2.3.1-38: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 ACK 

Content-Length: 

Cseq: Is required to be the same value as Cseq is original INVITE request [3]. 

39. ACK (P-CSCF to S-CSCF) - see example in table 7.2.3.1-39 

P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the ACK request to S-CSCF. 

Table 7.2.3.1-39: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:scscfl. homel . net; lr>, <sip : scscf2 . home 2 .net;lr>, <sip:pcscf2. home 2 .net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

Route: Saved from the Record-Route header of the 183 Session Progress response. 

40. ACK (MO#2 to S-S) - see example in table 7.2.3.1-40 

S-CSCF forwards the ACK request to the terminating endpoint, per the S-CSCF to S-CSCF procedure. 

Table 7.2.3.1-40: ACK (M0#2 to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



7.2.3.2 Failure in termination procedure 

The roaming subscriber that initiated a session with procedure MO#2 had the attempt fail due to an error detected in the 
Termination procedure or in the S-CSCF-to-S-CSCF procedure. This could be due to, for example, destination busy 
(error code 486), destination service denied (error code 403), destination currently out of coverage (error code 480), or 
some other error. 

Depending on the exact error that causes the session initiation failure, and when the error situation was detected, UE#1 
could be at many different stages in the session establishment procedure. This is shown in figure 7.2.3.2-1, as optional 
messages 7-33 that may appear in this error procedure. 
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Figure 7.2.3.2-1: Failure in termination procedure 
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1-6. INVITE (UE to P-CSCF) et seq 

UE#1 initiated a session, as described in subclause 7.2.3.1. 

7-33.100 Trying (S-S to MO#2) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.2.3.1. 

34. XXX Error (S-S to MO#2) - see example in table 7.2.3.2-34 

The termination procedure detected some error situation, and returned a SIP error response. 

NOTE 1: The error response may be, for example, "486 Busy", "403 Service Denied", "480 Temporarily 
Unavailable", or others. For this example, "486 Busy" is shown. 

Table 7.2.3.2-34: 486 Busy Here (S-S to M0#2) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ;branch=z9hG4bKnashds7 

From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>; tag=314159 
Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 
Retry-After: 3600 
Content-Length: 

35. ACK (MO#2 to S-S) - see example in table 7.2.3.2-35 

Upon receive the 486 response from the S-S procedure, S-CSCF sends ACK. 

Table 7.2.3.2-35: ACK (M0#2 to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route: <sip: scscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

36. XXX Error (S-CSCF to P-CSCF) - see example in table 7.2.3.2-36 (related to table 7.2.3.2-34) 

The S-CSCF returned a SIP error response to P-CSCF. 

NOTE 2: The error response may be, for example, "486 Busy", "403 Service Denied", "480 Temporarily 
Unavailable", or others. For this example, "486 Busy" is shown. 

Table 7.2.3.2-36: 486 Busy Here (S-CSCF to P-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Contact : 
Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

37. ACK (P-CSCF to S-CSCF) - see example in table 7.2.3.2-37 
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Upon receive the 486 response from the S-CSCF procedure, P-CSCF sends ACK. 
Table 7.2.3.2-37: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1 

Max-Forwards: 70 

Route: <sip: scscfl .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

38. Revoke QoS authorization 

P-CSCF removes the QoS authorization, if any, for this session. 

39. XXX Error (P-CSCF to UE) - see example in table 7.2.3.2-39 (related to table 7.2.3,2-36) 

The P-CSCF returned a SIP error response to UE. 

NOTE 3: The error response may be, for example, "486 Busy", "403 Service Denied", "480 Temporarily 
Unavailable", or others. For this example, "486 Busy" is shown. 

Table 7.2.3.2-39: 486 Busy Here (P-CSCF to UE) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Contact : 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

40. ACK (P-CSCF to S-CSCF) - see example in table 7.2.3.2-40 

Upon receive the 486 response from the P-CSCF, UE sends ACK. 

Table 7.2.3.2-40: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

7.2.3.3 Session abandoned, or resource failure 

The roaming subscriber that initiated a session with procedure MO#2 either abandoned the attempt, or was unable to 
obtain the resources necessary for the session. The signalling flow for this error handling is shown in figure 7.2.3.3-1. 

If the session is aborted due to failure to obtain resources, it will occur at step #18 in the signalling flow; steps 19-33 
(marked as optional) will not be present. If the session is abandoned due to user command, it can happen at any point 
between steps 8-33. 
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Figure 7.2.3.3-1 : Session abandoned or resource failure 
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1-7. INVITE (UE to P-CSCF) et seq 

UE#1 initiated a session, as described in subclause 7.2.3.1. 

8-33.183 Session Progress (S-S to MO#2) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.2.3.1. 

34. CANCEL (UE to P-CSCF) - see example in table 7.2.3.3-34 

The UE cancelled the original INVITE request. 

Table 7.2.3.3-34: CANCEL (UE to P-CSCF) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 CANCEL 
Content-Length: 

35. 200 OK (P-CSCF to UE) - see example in table 7.2.3.3-35 

Upon receive the CANCEL request from the UE, P-CSCF sends 200 OK. 

Table 7.2.3.3-35: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

36. Revoke QoS authorization 

P-CSCF removes the QoS authorization, if any, for this session. 

37. CANCEL (P-CSCF to S-CSCF) - see example in table 7.2.3.3-37 (related to table 7.2.3.3-34) 

The P-CSCF forwards the CANCEL request to S-CSCF. 

Table 7.2.3.3-37: CANCEL (P-CSCF to S-CSCF) 

CANCEL sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 69 
Route: <sip: scfcfl .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

38. 200 OK (S-CSCF to P-CSCF) - see example in table 7.2.3.3-38 

Upon receiving the CANCEL request from the P-CSCF, S-CSCF sends 200 OK. 

Table 7.2.3.3-38: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



39. CANCEL (S-CSCF to S-S) - see example in table 7.2.3.3-39 (related to table 7.2.3.3-37) 

The S-CSCF forwards the CANCEL request to the appropriate S-CSCF-to-S-CSCF procedure. 

Table 7.2.3.3-39: CANCEL (S-CSCF to S-S) 

CANCEL sip: [555:eee:fff :aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 
Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Content-Length : 

40. 200 OK (S-S to S-CSCF) - see example in table 7.2.3.3-40 

Upon receive the CANCEL request from the S-CSCF, the next hop (whatever it is) sends 200 OK. 

Table 7.2.3.3-40: 200 OK (S-S to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

4L 487 Cancelled (S-S to MO#2) - see example in table 7.2.3.3-41 

The termination procedure cancelled the request, and returned a SIP error response to the original INVITE 
request. 



Table 7.2.3.3-41 : 487 Cancelled (S-S to M0#2) 



SIP/2.0 487 Cancelled 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 
Call-ID: 

CSeq: 127 INVITE 
Content-Length: 



42. ACK (MO#2 to S-S) - see example in table 7.2.3.3-42 

Upon receive the 487 response from the S-S procedure, S-CSCF sends ACK. 

Table 7.2.3.3-42: ACK (M0#2 to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards 70 

Route: <sip: scscf 2 .home2 . net; lr> 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



126 



ETSI TS 124 228 V5.3.0 (2002-12) 



From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length : 



43. 487 Cancelled (S-CSCF to P-CSCF) - see example in table 7.2.3.3-43 (related to table 7.2.3.3-41) 

The S-CSCF returned the SIP error response to P-CSCF. 

Table 7.2.3.3-43: 487 Cancelled (S-CSCF to P-CSCF) 

SIP/2.0 487 Cancelled 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Contact : 
Call-ID: 
CSeq: 
Content-Length: 

44. ACK (P-CSCF to S-CSCF) - see example in table 7.2.3.3-44 

Upon receive the 487 response from the S-CSCF, P-CSCF sends ACK. 

Table 7.2.3.3-44: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1 

Max-Forwards: 70 

Route: <sip: scscfl .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

45. 487 Cancelled (P-CSCF to UE) - see example in table 7.2.3.3-45 (related to table 7.2.3.3-43) 
The P-CSCF returned a SIP error response to UE. 

Table 7.2.3.3-45: 487 Cancelled (P-CSCF to UE) 

SIP/2.0 487 Cancelled 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Contact : 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

46. ACK (UE to P-CSCF) - see example in table 7,2,3.3-46 

Upon receive the 487 response from the P-CSCF, UE sends ACK. 

Table 7.2.3.3-46: ACK (UE to P-CSCF) 

ACK sip:+l-212-555-2222@homel.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 
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7.2.4 (CS-0) CS Networks origination 



The MGCF in the IM subsystem is a SIP endpoint that initiates requests on behalf of the CS Networks origination and 
Media Gateway. The subsequent nodes consider the signalHng as if it came from a S-CSCF. The MGCF incorporates 
the network security functionaHty of the S-CSCF. This MGCF does not invoke Service Control, as this may be carried 
out in the CS Networks or at the terminating S-CSCF. This origination procedure can be used for any of the MT 
procedures. 

Due to routing of sessions within the CS Networks, this origination procedure will only occur in the home network of 
the destination subscriber. However, the destination subscriber may be roaming in a different operator's network. 
Further, due to cases of session forwarding and electronic surveillance, the destination of the session through the IM 
subsystem may actually be another CS Networks termination. 

7.2.4.1 CS Networks originated sessions routed towards IM CN subsystem (througli 

MGCF) (S-S#2, MT#2 assumed) 

This clause and figure 7.2.4.1-1 presents only the case of CS Networks originated sessions routed towards the IM CN 
subsystem reaching first a MGCF. 
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Figure l.^AAA : CS Networks origination 

The CS Networks Origination procedure is as follows: 

1. SS7:IAM 

The CS Network establishes a bearer path to the MGW, and signals to the MGCF with a lAM message, 
giving the trunk identity, destination information and optionally the continuity indication. 

2. H.248 Interaction 

The MGCF initiates a H.248 command, to seize the trunk and an IP port. 
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3. INVITE (CS-O to S-S) - see example in table 7.2.4.1-3 

The MGCF initiates an INVITE request, containing an initial SDP, as per the proper S-CSCF to S-CSCF 
procedure. 

Table 7.2.4.1-3: INVITE (CS-O to S-S) 

INVITE sip:+l-212-555-2222@homel.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bK779s24 . 

Max-Forwards; 70 

P-Preferred-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Charging-Vector ; icid-value=5678ef 32a62c; icid-generated-at= [5555 : ; 6a6 ; 7b7 ; 8c8 : 9d9] ; orig- 

ioi=homel . net 

Privacy; none 

From: <tel : +1-2 12-555-1 11 1>; tag=17 182 8 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: <sip: mgcf 1 .homel . net> 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Request-URI: Contains the keyed number from the user, as obtained from CS Networks signalling. 

Via: Contains the IP address or FQDN of the originating MGCF. 

P-Preferred-Identity:The user provides a hint about the identity to be used for this session. 

P-Charging- Vector: The MGCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the MGCF. 

From:/To:/Call-ID: Follow the recommendations of draft-ietf-sip-privacy [13], even though anonymity is not 
being requested for this session. 

Cseq: A random starting number. 

Contact: Is the SIP URL that contains the IP address or FQDN of the originating UE. 

SDP The SDP contains a preconfigured set of codecs supported by the MGW. 



4. 100 Trying (S-S to CS-O) - see example in table 7.2.4.1-4 

MGCF receives a 100 Trying provisional response, as specified by the S-CSCF to S-CSCF procedures. 

Table 7.2.4.1-4: 100 Trying (S-S to CS-O) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP mgcf 1 .homel . net; branch=z9hG4bK779s24 . 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 
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5. 183 Session Progress (S-S to CS-O) - see example in table 7.2.4.1-5 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response, per the S-CSCF to S-CSCF procedures. 

Table 7.2.4.1-5: 183 Session Progress (S-S to CS-O) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bK779s24 . 

Record-Route ; <sip;pcscf2. homel .net;lr>, <sip;scscf2. homel .net; lr> 

P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Charging-Vector : icid-value=5678ef 32a62c; icid-generated-at= [5555 ; ; 6a6 ; 7b7 ; 8c8 ; 9d9] ; orig- 

ioi=homel .net; term-ioi=visit 1 .net 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e661; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

Privacy: none 

From: 

To: <tel:+l-212-555-2222>; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 3 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

P-Charging-Function-Addresses: The S-CSCF passes this header to the MGCF for charging. 

Upon receiving the 183 Session Progress, the MGCF stores the following information about this session - 
see example in table 7.2.4.1 -6b. 



Table 7.2.4.1 -6b: Storage of information at MGCF 



Request-URI : sip : +l-212-555-2222@homel .net; user=phone 

From: <tel : +1-2 12-555-1 11 1>; tag=17 182 8 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

P-Charging-Vector : icid-value=5678ef 32a62c; icid-generated-at= [5555 : : 6a6 : 7b7 : 8c8 : 9d9] ; orig- 

ioi=homel .net; term-ioi=visit 1 .net 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d221; 

ecf=[5555::lff:2ee:3dd:4cc]; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

Route: <sip: scscf 2 .homel . net; lr>, <sip : pcscf 2 . homel . net ; lr> 

6. Possible bearer related negotiation takes place 

Steps 6 and 7 can be done in an arbitrary order. 

7. PRACK (CS-O to S-S) - see example in table 7.2.4.1-7 

MGCF decides the final set of media streams for this session, and includes this information in the PRACK 
request, send to the destination per the S-CSCF to S-CSCF procedures. 
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Table 7.2.4.1-7: PRACK (CS-0 to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 .homel . net; branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route: <sip: scscf 2 .homel . net; lr>, <sip:pcscf2 .homel . net; lr> 

From: <tel : +1-2 12-555-1 11 1>; tag=17 182 8 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 128 PRACK 

Require : 

Rack: 9021 127 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 



Request-URI: Takes the first component of the saved Route header. 

Via: Takes the value of either the IP address or FQDN of the originating MGCF. 

Route: Takes the saved Route header without the first component. 

From:/To:/Call-ID: Copied from the 183 Session Progress response so that they include any tag parameter. 

Cseq: Takes a higher value than that in the previous request. 

8. 200 OK (S-S to CS-O) - see example in table 7.2.4.1-8 

The destination responds to the PRACK request (7) with a 200 OK response. 

Table 7.2.4.1-8: 200 OK (S-S to CS-O) 

SIP/2.0 200 OK 

via: SIP/2. 0/UDP mgcf 1 .homel . net;branch=z9hG4bK779s24 . 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

9. H.248 Interaction 
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MGCF initiates a H.248 command to modify the connection parameters and instruct the MGW to reserve the 
resources needed for the session. 

10. Reserve Resources 

MGW reserves the resources needed for the session. 

11. COT 

In case the lAM had contained a continuity indication, the COT message arrives to the MGCF. 

12. UPDATE (CS-O to S-S) - see example in table 7.2.4.1-12 

When the resource reservation is completed and the possible COT message is received, MGCF sends the 
UPDATE request to the terminating endpoint, per the S-S procedures. 

Table 7.2.4.1-12: UPDATE (CS-O to S-S) 

UPDATE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route: <sip: scsf 2 .homel . net; lr>, <sip:pcscf 2 .homel . net; lr> 

From: <tel : +1-2 12-555-1 11 1>; tag=17 1828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 12 9 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

Request-URI: The first component of saved the Route header. 

Via: Contains the IP address or FQDN of the originating MGCF. 

Route: Takes the saved Route header without the first component. 

From:/To:/Call-ID: Copied from the 183 Session Progress response so that they include any tag parameters. 

Cseq: Takes a higher value than that in the previous request. 

The SDP indicates that the resource reservation was successful in the local segment. 
13. 200 OK (S-S to CS-O) - see example in table 7.2.4.1-13 

The destination endpoint responds to the UPDATE request (12) with a 200 OK response. 

Table 7.2.4.1-13: 200 OK (S-S to CS-O) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mgcf 1 .homel .net;branch=z9hG4bK779s24 . 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 
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o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 



The SDP indicates that the resource reservation was successful both in the local and the remote segment. 

14. 180 Ringing (S-S to CS-O) - see example in table 7.2.4.1-14 

The destination endpoint may optionally perform alerting. If so, it signals this to the calling party by a 180 
Ringing provisional response. This response is sent to MGCF per the S-CSCF to S-CSCF procedure. 



Table 7.2.4.1-14: 180 Ringing (S-S to CS-O) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ;branch=z9hG4bK779s24 . 

Record-Route ; <sip:pcscf2. homel .net;lr>^ <sip;scscf2. homel .net; lr> 

Require: lOOrel 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9022 

Content-Length: 



15. PRACK (CS-O to S-S) - see example in table 7.2.4.1-15 

MGCF acknowledges the 180 Ringing provisional response (14) with a PRACK request. MGCF adds the 
Route header corresponding to the session. 

Table 7.2.4.1-15: PRACK (CS-O to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route: <sip: scscf 2 .homel . net; lr>, <sip:pcscf 2 .homel . net; lr> 

From: <tel : +1-2 12-555-1 11 1>; tag=17 182 8 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call-ID: 

Cseq: 130 PRACK 

Rack: 9022 127 INVITE 

Content-Length: 

16. 200 OK (S-S to CS-O) - see example in table 7.2.4.1-16 

The destination endpoint responds to the PRACK request (15) with a 200 OK response. 

Table 7.2.4.1-16: 200 OK (S-S to CS-O) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mgcf 1 .homel . net; branch=z9hG4bK779s24 . 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

17. SS7: ACM 

If alerting is being performed, the MGCF forwards an ACM message. 
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18. 200 OK (S-S to CS-O) - see example in table 7.2.4.1-18 

When the called party answers, the terminating and S-S procedures result in a 200 OK final response being 
sent to MGCF. 

Table 7.2.4.1-18: 200 OK (S-S to CS-O) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bK779s24 . 

Record-Route : <sip;pcscf2. homel .net;lr>, <sip:scscf2. homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

Content-Length: 

19. SS7: ANM 

MGCF forwards an ANM message to the CS Networks. 

20. H.248: Interaction 

MGCF initiates a H.248 command to alter the connection at MGW to make it bidirectional. 

21. ACK (CS-O to S-S) - see example in table 7.2.4.1-21 

MGCF acknowledges the 200 OK final response (18) with an ACK request. 

Table 7.2.4.1-21 : ACK (CS-O to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route: <sip:pcscf2 .homel . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 127 ACK 

Content-Length: 

Request-URI: the first component of the saved Route header. 

Route: takes the saved Route header without the first component. 

Cseq: is required to be the same value as Cseq is original INVITE request [3] 

7.2.4.2 CS Networks originated sessions routed towards CS domain (through G- 
MSC) (not provided) 

An example of this flow is not shown in the present document. 

7.2.4.3 CS Networks originated sessions routed either towards IM CN subsystem or 
towards CS domain (not provided) 

An example of this flow is not shown in the present document. 

7.2.4.4 Failure in termination procedure 

The PSTN subscriber that initiated a session with procedure CS-O had the attempt fail due to an error detected in the 
Termination procedure or in the S-CSCF-to-S-CSCF procedure. This could be due to, for example, destination busy 
(error code 486), destination service denied (error code 403), destination currently out of coverage (error code 480), or 
some other error. 
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Depending on the exact error that causes the session initiation failure, and when the error situation was detected, the 
originator could be at many different stages in the session establishment procedure. This is shown in figure 7.2.4.4-1, as 
optional messages 5-17 that may appear in this error procedure. 



PSTN 



T-SGW 



-1. lAM ► 



-^ 17. ACM 



< 21. REL- 



Home Network 



MGW 



MGCF 



2. IP-IAM- 

I 



3. H.248 interaction to 
create connection 



—4. INVITE ► 

-5. 100 Trying 

6. 183 SDP 

7. PRACK ► 

8. 200 OK 



9. H.248 interaction to 

modify connection 
to reserve resources 



10. Resource 
Reservation 



11. UPDATE 
rt 12. 200 OK 



16. IP-ACM 



-20. IP-REL- 



113. 180 Ringing 
-14. PRACK > 
h-15. 200 OK 



-18. XXX Error- 
— 19. ACK — 



22. H.248 interaction to 
delete connection 



Figure 7.2.4.4-1: Failure in termination procedure 

4. INVITE (MGCF to S-S) et seq 

The PSTN originator initiated a session, as described in subclause 7.2.4.1. 

5-17.100 Trying (S-S to CS-O) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.2.4.1. 

18. XXX Error (S-S to CS-O) - see example in table 7.2.4.4-18 

The termination procedure detected some error situation, and returned a SIP error response. 
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NOTE 1: The error response may be, for example, "486 Busy", "403 Service Denied", "480 Temporarily 
Unavailable", or others. For this example, "486 Busy" is shown. 

Table 7.2.4.4-18: 486 Busy Here (S-S to CS-0) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP mgcf 1 .homel . net; branch=z9hG4bK779s24 . 

From: <tel : +1-2 12-555-1 11 1>; tag=17 182 8 

To: <tel:+l-212-555-2222>;tag=31415 9 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Retry-After: 3600 

Content-Length: 

19. ACK (CS-O to S-S) - see example in table 7.2.4.4-19 

Upon receive the 486 response from the S-S procedure, S-CSCF sends ACK. 

Table 7.2.4.4-19: ACK (CS-0 to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bK779s24 . 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

20. H.248 Interaction 

MGCF initiates a H.248 interaction with MGW to delete the connection. 

7.2.4.5 Session abandoned, or resource failure 

The PSTN subscriber that initiated a session with procedure CS-O either abandoned the attempt, or was unable to obtain 
the resources necessary for the session. The signalling flow for this error handling is shown in figure 7.2.4.5-1. 

If the session is aborted due to failure to obtain resources, it will occur at step #10 in the signalling flow; steps 11-17 
(marked as optional) will not be present. If the session is abandoned due to user command, it can happen at any point 
between steps 5-17. 
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11. UPDATE ► 
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Figure 7.2.4.5-1 : Session abandoned or resource failure 

4. INVITE (CS-O to S-S) et seq 

CS-O initiated a session, as described in subclause 7.2.4.1. 

5-15. 183 SDP (S-S to CS-O) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.2.4.1. 

20. CANCEL (CS-O to S-S) - see example in table 7.2.4.5-20 

The PSTN cancelled the original INVITE request. 

Table 7.2.4.5-20: CANCEL (CS-O to S-S) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 .homel . net; branch=z9hG4bK779s24 . 

Max-Forwards: 70 
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Route: <sip: scscf 2 .homel . net; lr>, <sip:pcscf 2 .homel . net; lr> 

From: <tel : +1-2 12-555-1 11 1>; tag=17 182 8 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 CANCEL 

Content-Length: 



21. 200 OK (S-S to CS-O) - see example in table 7.2.4.5-21 

Upon receive the CANCEL request from CS-O, the S-S procedure sends 200 OK. 

Table 7.2.4.5-21 : 200 OK (S-S to CS-O) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mgcfl . homel . net ; branch=z9hG4bK779s24 . 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

22. H.248 Interaction 

MGCF initiates a H.248 interaction with MGW to delete the connection 
23. 487 Cancelled (S-S to CS-O) - see example in table 7.2.4.5-23 

The termination procedure processed the CANCEL request, and returned a SIP error response. 

Table 7.2.4.5-23: 487 Cancelled (S-S to CS-O) 

SIP/2.0 487 Cancelled 

Via: SIP/2. 0/UDP mgcfl . homel . net ; branch=z9hG4bK779s24 . 

From: 

To: 

Contact : 

Call-ID: 

Cseq: 127 INVITE 

Retry-After: 3600 

Content-Length: 

24. ACK (CS-O to S-S) - see example in table 7.2.4.5-24 

Upon receive the 487 response from the S-S procedure, MGCF sends ACK. 

Table 7.2.4.5-24: ACK (CS-O to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP mgcfl . homel . net ; branch=z9hG4bK779s24 . 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

7.2.5 Error handling: origination procedures (not provided) 

An example of this flow is not shown in the present document. 

7.3 S-CSCF (MGCF) to S-CSCF (MGCF) procedures 
7.3.1 Introduction 
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This subclause presents the detailed signalling flows to define the procedures for S-CSCF to S-CSCF. 

This subclause contains four signalling flow procedures, showing variations on the signalling path between the S-CSCF 
(or MGCF) that handles session origination, and the S-CSCF (or MGCF) that handles session termination. This 
signalling path depends on: 

whether the originator and destination are served by the same network operator; 

agreements between operators for optimum PSTN gateway location. 

Between separate operators, there are additional sub-cases covering the optional network configuration hiding - hiding 
required by both operators, neither operator, or just one operator. 

The S-CSCF handling session origination performs an analysis of the destination address, and determines whether it is a 
PSTN destination, a subscriber of the same network operator or a subscriber of a different operator. 

If the analysis of the destination address determined that it belongs to a subscriber of a different operator, the request is 
forwarded (optionally through an I-CSCF within the originating operator's network) to a well-known entry point in the 
destination operator's network, the I-CSCF. The I-CSCF queries the HSS for current location information. The I-CSCF 
then forwards the request to the S-CSCF. This is signalling flow procedure S-S#l. 

If the analysis of the destination address determines that it belongs to a subscriber of the same operator, the S-CSCF 
forwards the request to a local I-CSCF, who queries the HSS for current location information. The I-CSCF then 
forwards the request to the S-CSCF. This is signalling flow procedure S-S#2. 

If the analysis of the destination address determines that it is a PSTN destination, the S-CSCF forwards the request to a 
local BGCF. Based on further analysis of the destination address, and on agreements between operators for PSTN 
termination, the BGCF will either select a local MGCF to perform the termination (procedure S-S#3) or will forward 
the request to a BGCF in another operator's network who will select the MGCF to perform the termination (procedures 

S-S#4). 

7.3.2 S-S#1a 

7.3.2.1 (S-S#1a) Different network operators performing origination and termination 

(M0#1a, MT#1 a assumed) 

Figure 7.3.2.1-1 shows a S-CSCF handling session origination (S-CSCF#1), which performs an analysis of the 
destination address, and determines that it belongs to a subscriber of a different operator. The originating network 
operator does not desire to keep their configuration hidden, so it forwards the request to a well-known entry point in the 
destination operator's network, I-CSCF. I-CSCF queries the HSS for current location information, and finds the S-CSCF 
assigned to the subscriber (S-CSCF#2), and forwards the request to S-CSCF#2. The terminating network operator does 
not desire to keep their configuration hidden, so the I-CSCF does not insert itself into the signalling path for future 
exchanges. This example flow does not show Application Server involvement. 

Origination sequences that share this common S-CSCF to S-CSCF procedure are: 

MO#la Mobile origination, roaming, without a THIG. The "Originating Network" of S-S#la is therefore a 

visited network. 

MO#lb Mobile origination, roaming, with a THIG in home network. The "Originating Network" of S- 

S#la is therefore a visited network. 

MO#2 Mobile origination, located in home service area. The "Originating Network" of S-S#la is 

therefore the home network. 

CS-O CS Networks origination. The "Originating Network" of S-S#la is the home network. The element 

labelled S-CSCF#1 is the MGCF of the CS-O procedure. 

Termination sequences that share this common S-CSCF to S-CSCF procedure are: 

MT#la Mobile termination, roaming, without a THIG. The "Terminating Network" of S-S#la is a visited 

network. 
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MT#lb 



MT#2 



Mobile termination, roaming, with a THIG in home network. The "Terminating Network" of S- 
S#la is a visited network. 

Mobile termination, located in home service area. The "Terminating Network" of S-S#la is the 
home network. 
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Figure 7.3.2.1-1 :S-S#1 a 

Procedure S-S#la is as follows: 

1 . INVITE (MO to S-S#la) - see example in table 7.3.2.1-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 7.3.2.1-1 : INVITE (MO to S-S#1a) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
lyiax-Forwards ; 69 

Route; <sip; scscf 1 .homel . net; lr> 
Record-Route ; <sip;pcscfl. visitedl. net;lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; dSd; c2c] 
Privacy: none 
From: <sip : userl_publicl@homel . net>; tag=171828 
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To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: <sip: [5555: : aaa:bbb: ccc : ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 



o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video 3402 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



2. 100 Trying (S-S#la to MO) - see example in table 7.3.2.1-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.3.2.1-2: 100 Trying (S-S#1a to MO) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

3. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For this 
example, assume no Application Server involvement. 
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4. INVITE (S-CSCF to I-CSCF) - see example in table 7.3.2.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, S-CSCF#1 forwards the INVITE request directly to to I-CSCF in the destination 
network. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 

Table 7.3.2.1-4: INVITE (S-CSCF to I-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl.visitedl.net;lr> 
P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel . net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP-URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
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an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

P-Asserted-Identity: The S-CSCF adds the corresponding TEL URL to the P-Asserted-Identity header in order that 
the TEL URL is known to the destination network in case the INVITE is forwarded to a MGCF. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 

5. 100 Trying (I-CSCF to S-CSCF) - see example in table 7.3.2.1-5 

I-CSCF responds to the INVITE request (4) by sending a 100 Trying provisional response to S-CSCF#1. 

Table 7.3.2.1-5: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK24 0f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

6. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [11]. 

Table 6.3.2-6a provides the parameters in the SIP INVITE request (flow 4), which are sent to the HSS. 

Table 7.3.2. 1-6a Cx: User registration status query procedure (I-CSCF to HSS) 



Message source & 
destination 


Cx: Information 
element name 


Information source 
in SIP INVITE 


Description 


I-CSCF to HSS 


User Public 
Identity 


Request-URI: 


This information 
element indicates the 
public user Identity 



Table 7.3.2. l-6b provides the parameters sent from the HSS that need to be mapped to SIP INVITE (flow 7) 
and sent to S-CSCF. 

Table 7.3.2. 1-6b Cx: User registration status query procedure (HSS to I-CSCF) 



Message source & 


Cx: Information 


Mapping to SIP 


Description 


destination 


element name 


header in SIP 
INVITE 




HSS to I-CSCF 


S-CSCF name 


Route header field 


This information indicates 
the serving CSCF's name 
of that user 



7. INVITE (I-CSCF to S-CSCF) - see example in table 7.3.2.1-7 

I-CSCF forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 7.3.2.1-7: INVITE (I-CSCF to S-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip: scscf 2 .home2 . net; lr> 
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Record-Route : <sip:scscfl .homel . net; lr>, <sip:pcscf 1 . visitedl . net; lr> 

P -Asserted- Identity ; 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o = 
s = 



NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

8. 100 Trying (S-CSCF to I-CSCF) - see example in table 7.3.2.1-8 

S-CSCF#2 responds to the INVITE request (7) with a 100 Trying provisional response. 

Table 7.3.2.1-8: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .visitedl . net;branch=z9hG4bK240f 34 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : COG : ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

9. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. 
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10. INVITE (S-S#la to MT) - see example in table 7.3.2.1-10 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 

S-CSCF#2 examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 

Table 7.3.2.1-10: INVITE (S-S#1a to MT) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/ 2. 0/UDP scscf 1 . home 1 . net ; branch=z9hG4bK332b2 3 . 1, 
SIP/ 2 .0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : <sip:pcscf2.visited2.net;lr> 

Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 

P-Called-Party-ID: <sip: user2_publicl@home2 . net> 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

1 1. 100 Trying (MT to S-S#la) - see example in table 7.3.2.1-11 (related to table 7.3.2.1-10) 
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S-CSCF#2 receives a 100 Trying provisional response to the INVITE request (10), as specified by the 
termination procedures. 

Table 7.3.2.1-11: 100 Trying (MTtoS-S#1a) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2 .0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

12. 183 Session Progress (MT to S-S#la) - see example in table 7.3.2.1-12 (related to table 7.3.2.1-10) 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response to the INVITE request (10), as per the termination procedure. 

Table 7.3.2.1-12: 183 Session Progress (MT to S-S#1a) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/2. 0/UDP scscf 1 . home 1 . net ; branch=z9hG4bK3 32b2 3 . 1, 
SIP/ 2 .0/UDP pcscf 1 .visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel . net ; lr>, 
<sip : pcscf 1 .visitedl . net; lr> 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy: none 
From: 

To: <tel:+l-212-555-2222>; tag=314159 
Call-ID: 
CSeq: 

Require: lOOrel 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

C=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

13. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 7.3.2.1-13 

S-CSCF#2 forwards the 183 Session Progress provisional response to 1-CSCF. 

Table 7.3.2.1-13: 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 
SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Record-Route : 

P-Asserted-Identity ; "John Smith" <sip ; user2_publicl@home2 . net>, <tel ; +l-212-555-2222> 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 : ; f 5f ; e4e ; d3d; c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: See: 9dd] 

Privacy : 

From; 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



P-Asserted-Identity: The S-CSCF adds the corresponding TEL URL to the P-Asserted-Identity header in order that 
the TEL URL is known to the destination network in case the INVITE is forwarded to a MGCF. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 

14. 183 Session Progress (I-CSCF to S-CSCF) - see example in table 7.3.2.1-14 

I-CSCF forwards the 183 Session Progress provisional response to S-CSCF#1. 

Table 7.3.2.1-14: 183 Session Progress (I-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 
P-Charging-Vector : 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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15. 183 Session Progress (S-S#la to MO) - see example in table 7.3.2.1-15 

S-CSCF#1 forwards the 183 Session Progress to the originator, as per the originating procedure. 

Table 7.3.2.1-15: 183 Session Progress (S-S#1a to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 : ; f 5f ; e4e : d3d; c2c] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



16. PRACK (MO to S-S#la) - see example in table 7.3.2.1-16 

The originator decides the final set of media streams, and includes this information in the PRACK request 
sent to S-CSCF#1 by the origination procedures. 

Table 7.3.2.1-16: PRACK (MO to S-S#1a) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip: cscf 2 . visited2 . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 128 PRACK 
Require: precondition 
Rack: 9021 127 INVITE 
Content-Type: application/sdp 
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Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



17. PRACK (S-CSCF to S-CSCF) - see example in table 7.3.2.1-17 

S-CSCF#1 forwards the PRACK request to S-CSCF#2. 

Table 7.3.2.1-17: PRACK (S-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



18. PRACK (S-S#la to MX) - see example in table 7.3.2.1-18 

S-CSCF#2 forwards the PRACK request to the terminating endpoint, as per the termination procedure. 

Table 7.3.2.1-18: PRACK (S-S#1a to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Require : 
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Rack: 

Content-Type : 
Content-Length ; 



19. 200 OK (MT to S-S#la) - see example in table 7.3.2.1-19 (related to table 7.3.2.1-18) 

The terminating endpoint responds to the PRACK request (18) with a 200 OK response. 

Table 7.3.2.1-19: 200 OK (MT to S-S#1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



20. 200 OK (S-CSCF to S-CSCF) - see example in table 7.3.2.1-20 

S-CSCF#2 forwards the 200 OK response to S-CSCF#1. 

Table 7.3.2.1-20: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 
Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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21. 200 OK (S-S#la to MO) - see example in table 7.3.2.1-21 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.2.1-21 : 200 OK (S-S#1a to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



22. UPDATE (MO to S-S#la) - see example in table 7.3.2.1-22 

When the originating endpoint has completed the resource reservation procedures, it sends the UPDATE 
request to S-CSCF#1 by the origination procedures. 

Table 7.3.2.1-22: UPDATE (MO to S-S#1a) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 129 UPDATE 
Content-Type: application/sdp 
Content-Lengtli: (...) 

v=0 
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o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr;qos local sendrecv 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



23. UPDATE (S-CSCF to S-CSCF) - see example in table 7.3.2.1-23 

S-CSCF#1 forwards the UPDATE request to S-CSCF#2. 



Table 7.3.2.1-23: UPDATE (S-CSCF to S-CSCF) 



UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



24. UPDATE (S-S#la to MT) - see example in table 7.3.2.1-24 

S-CSCF#2 forwards the UPDATE request to the terminating endpoint, as per the termination procedure. 

Table 7.3.2.1-24: UPDATE (S-S#1a to MT) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; brancli=z9hG4bKnaslids7 
Max-Forwards : 67 
Route : <sip:pcscf2.visited2.net;lr> 

P-Clnarging-Vector : icid-value = 1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Lengtln : 
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25. 200 OK (MT to S-S#la) - see example in table 7.3.2.1-25 (related to table 7.3.2.1-24) 

The terminating endpoint responds to the UPDATE request (24) with a 200 OK response. 

Table 7.3.2.1-25: 200 OK (MT to S-S#1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

26. 200 OK (S-CSCF to S-CSCF) - see example in table 7.3.2.1-26 

S-CSCF#2 forwards the 200 OK response to S-CSCF#1. 

Table 7.3.2.1-26: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 
Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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27. 200 OK (S-S#la to MO) - see example in table 7.3.2.1-27 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.2.1-27: 200 OK (S-S#1a to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



28. 180 Ringing (MT to S-S#la) - see example in table 7.3.2.1-28 (related to table 7.3.2.1-10) 

The terminating endpoint may optionally send a 180 Ringing provisional response indicating alerting is in 
progress. This response is sent by the termination procedure to S-CSCF#2. 



Table 7.3.2.1-28: 180 Ringing (MT to S-S#1a) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr>^ 
<sip:pcscfl .visitedl . net; lr> 
P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 



:eee:fff:aaa: bbb] > 



From: 
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Call- 


ID; 
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29. 180 Ringing (S-CSCF to I-CSCF) - see example in table 7.3.2.1-29 

S-CSCF#2 forwards the 180 Ringing response to I-CSCF. 

Table 7.3.2.1-29: 180 Ringing (S-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 
P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 : ; f 5f ; e4e : d3d; c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
From; 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

30. 180 Ringing (I-CSCF to S-CSCF) - see example in table 7.3.2.1-30 

I-CSCF forwards the 180 Ringing response to S-CSCF#1. 

Table 7.3.2.1-30: 180 Ringing (I-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

31. 180 Ringing (S-S#la to MO) - see example in table 7.3.2.1-31 

S-CSCF#1 forwards the 180 Ringing response to the originator, per the origination procedure. 

Table 7.3.2.1-31 : 180 Ringing (S-S#1a to MO) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

32. PRACK (MO to S-S#la) - see example in table 7.3.2.1-32 

The originator acknowledges the 180 Ringing provisional response (31) with a PRACK request. 
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Table 7.3.2.1-32: PRACK (MO to S-S#1a) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel .net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 

33. PRACK (S-CSCF to S-CSCF) - see example in table 7.3.2.1-33 

S-CSCF#1 forwards the PRACK request to S-CSCF#2. 

Table 7.3.2.1-33: PRACK (S-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 
Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

34. PRACK (S-S#la to MX) - see example in table 7.3.2.1-34 

S-CSCF#2 forwards the PRACK request to the terminating endpoint. 

Table 7.3.2.1-34: PRACK (S-S#1a to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 
Route : <sip:pcscf2.visited2.net;lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

35. 200 OK (MT to S-S#la) - see example in table 7.3.2.1-35 (related to table 7.3.2.1-34) 

The terminating endpoint responds to the PRACK request (34) with a 200 OK response. 

Table 7.3.2.1-35: 200 OK (MT to S-S#1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
CSeq: 
Content-Length: 
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36. 200 OK (S-CSCF to S-CSCF) - see example in table 7.3.2.1-36 

S-CSCF#2 forwards the 200 OK response to S-CSCF#1. 

Table 7.3.2.1-36: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 ; ; aaa ; bbb : ccc ; ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
CSeq: 
Content-Length : 

37. 200 OK (S-S#la to MO) - see example in table 7.3.2.1-37 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.2.1-37: 200 OK (S-S#1a to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 
Call-ID: 
CSeq: 
Content-Length : 

38. 200 OK (MX to S-S#la) - see example in table 7.3.2.1-38 (related to table 7.3.2.1-10) 

The final response to the INVITE request (10), 200 OK, is sent by the terminating endpoint over the 
signalling path. This is typically generated when the subscriber has accepted the incoming session attempt. 
The response is sent to S-CSCF#2 per the termination procedure. 

Table 7.3.2.1-38: 200 OK (MT to S-S#1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2 .0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr>, 
<s ip: pcscf 1 .visitedl . net; lr> 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-to]ten=86243614; flow-id=3 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 
Content-Length : 

39. 200 OK (S-CSCF to I-CSCF) - see example in table 7.3.2.1-39 

The 200 OK response is forwarded to the I-CSCF. 

Table 7.3.2.1-39: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
From: 
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To: 

Call-ID: 
CSeq: 
Contact : 

Content-Length : 



40. 200 OK (I-CSCF to S-CSCF) - see example in table 7.3.2.1-40 

The 200 OK response is forwarded to S-CSCF#1. 

Table 7.3.2.1-40: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 
P-Charging-Vector : 

From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

41. 200 OK (S-S#la to MO) - see example in table 7.3.2.1-41 

The 200 OK response is returned to the originating endpoint, by the origination procedure. 

Table 7.3.2.1-41 : 200 OK (S-S#1a to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

42. ACK (MO to S-S#la) - see example in table 7.3.2.1-42 

The originating endpoint sends the final acknowledgement to S-CSCF#1 by the origination procedures. 

Table 7.3.2.1-42: ACK (MO to S-S#1a) 

ACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: cb03a0s0 9a2sdf gilt j 4 90333 
Cseq: 127 ACK 
Content-Length: 

43. ACK (S-CSCF to S-CSCF) - see example in table 7.3.2.1-43 

S-CSCF#1 forwards the ACK request to S-CSCF#2. 

Table 7.3.2.1-43: ACK (S-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 

Route; <sip; scscf 2 .home2 . net; lr>, <sip;pcscf 2 . visited2 . net; lr> 
From; 
To; 

Call-ID; 
Cseq; 
Content-Length ; 

44. ACK (S-S#la to MT) - see example in table 7.3.2.1-44 

S-CSCF#2 forwards the ACK request to the terminating endpoint, as per the termination procedure. 

Table 7.3.2.1-44: ACK (S-S#1a to MT) 

ACK sip; [5555; ;eee;fff;aaa;bbb] SIP/2.0 

Via; SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa; bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards ; 67 
Route ; <sip;pcscf2.visited2.net;lr> 
From; 
To; 

Call-ID; 
Cseq; 
Content-Length ; 



7.3.2.2 Termination failure 

The subscriber that originated a session with one of the MO procedures had the attempt fail due to an error detected in 
the termination procedure. This could be due to, for example, destination busy (error code 486), resource failure (error 
code 580), or some other error. 

Depending on the exact error that causes the session initiation failure, and when the error situation was detected, the S- 
CSCF-to-S-CSCF procedure could be at many different stages in the session establishment procedure. This is shown in 
figure 7.3.2.2-1, as optional messages 12-38 that may appear in this error procedure. 
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Originating Networl< Home Networl<#1 



Home Networl<#2 



Terminating Networl< 



S-CSCF#1 



— 1. INVITE- 
-2. 100 Trying 



l-CSCF 



3. Evaluation of 
initial filter criterias 



-15. 183 SDP — 
-16. PRACK ♦ 



-21. 200 OK — 
-22. UPDATE -I 



*31. 180 Ringing 
32. PRACK - 



— 4. INVITE- 
-5. 100 Trying 



-14. 183 SDP-- 




-30. 180 Ringing- 



-42. XXX Error- 
43.ACK 



HSS 



/6. Cx: User location 
\ query 



S-CSCF#2 



. INVITE - 
-8. 100 Trying 



9. Evaluation of 
initial filter criterias 



Ringing - 



-40. xxj: Error- 
41. ACK — 



— 10. INVITE — 
-11. 100 Trying - 
-12. 183 SDP 



— 18. PRACK- 
K-19.200OK- 



— 24. UPDATE 
1—25. 200 OK- 



♦ 28. 180 Ringing 



— 34. PRACK- 
1—35. 200 OK- 



-38. XXX Error 
— 39. ACK — 



-44. XXX Error- 
— 45. ACK 



Figure 7.3.2.2-1 : Failure in termination procedure 

1-lO.INVITE (MO to S-CSCF) et seq 

A subscriber of the originating network initiated a session, as described in subclause 7.3.2.1. 

1 1-37. 100 Trying (MT to S-CSCF) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.3.2.1. 

38. XXX Error (MT to S-CSCF) - see example in table 7.3.2.2-38 

The termination procedure detected some error situation, and returned a SIP error response. 

NOTE 1 : The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 

Unavailable)", "580 (Precondition Failure)", or others. For this example, "486 (Busy Here)" is shown. 



Table 7.3.2.2-38: 486 Busy Here (MT to S-CSCF) 



SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 2 .home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 
scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: <sip : userl_publicl@homel . net>; tag=171828 
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To: <tel:+l-212-555-2222>; tag=314159 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Retry-After: 3600 

Content-Length: 



39. ACK (S-CSCF to MT) - see example in table 7.3.2.2-39 

Upon receive the 486 response from the MT procedure, S-CSCF sends ACK. 

Table 7.3.2.2-39: ACK (S-CSCF to MT) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 
Call-ID: 
CSeq: 127 ACK 
Content-Length: 

40. XXX Error (S-CSCF to I-CSCF) - see example in table 7.3.2.2-40 (related to table 7.3.2.2-38) 

The S-CSCF returned a SIP error response to I-CSCF. 

NOTE 2: The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 



Table 7.3.2.2-40: 486 Busy Here (S-CSCF to I-CSCF) 



SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 



41. ACK (I-CSCF to S-CSCF) - see example in table 7.3.2.2-41 

Upon receive the 486 response from the S-CSCF procedure, I-CSCF sends ACK. 

Table 7.3.2.2-41 : ACK (I-CSCF to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK332b23 . 1 

Route : <sip:scscf2. home 2 . net ; lr> 
From: 
To: 

Call-ID: 
CSeq: 127 ACK 
Content-Length: 

42. XXX Error (I-CSCF to S-CSCF) - see example in table 7.3.2.2-42 (related to table 7,3.2,2-40) 

The I-CSCF returned a SIP error response to S-CSCF. 

NOTE 3: The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 



Table 7.3.2.2-42: 486 Busy Here (I-CSCF to S-CSCF) 



SIP/2.0 486 Busy Here 
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Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 
Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

43. ACK (S-CSCF to I-CSCF) - see example in table 7.3.2.2-43 

Upon receive the 486 response from the S-CSCF procedure, I-CSCF sends ACK. 

Table 7.3.2.2-43: ACK (S-CSCF to I-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 
Call-ID: 
CSeq: 127 ACK 
Content-Length: 

44. XXX Error (S-CSCF to MO) - see example in table 7.3.2.2-44 (related to table 7.3.2.2-42) 

The S-CSCF returned a SIP error response to the appropriate MO procedure. 

NOTE 4: The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 

Table 7.3.2.2-44: 486 Busy Here (S-CSCF to MO) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 
To: 

Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

45. ACK (MO to S-CSCF) - see example in table 7.3.2.2-45 

Upon receiving the 486 response from the S-CSCF, the MO procedure sends ACK. 

Table 7.3.2.2-45: ACK (MO to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

Route: <sip: scscf 1 .homel . net; lr> 

From: 
To: 

Call-ID: 
CSeq: 127 ACK 
Content-Length: 



7.3.2.3 Origination failure 

The subscriber that initiated a session with one of the MO procedures either abandoned the attempt, or was unable to 
obtain the resources necessary for the session. The signalling flow for this error handling is shown in figure 7.3.2.3-1. 

If the session is aborted due to failure to obtain resources, it will occur at step #23 in the signalling flow; steps 23-38 
(marked as optional) will not be present. If the session is abandoned due to user command, it can happen at any point 
between steps 13-38. 
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Originating Networl< Home Networl<# 1 



Home Networl<#2 



Terminating Networl< 



S-CSCF#1 



— 1. INVITE — 
-2. 100 Trying — 



l-CSCF 



3. Evaluation of Initial 
filter criterlas 



■♦-- 15.183 
16. PRACK- 



»— 21. 200 OK- 
— -22. UPDATE-- 



-27. 200 OK- 



-431. 180 Ringing 
32. PRACK- 



»— 37. 200 OK- 



-38. CANCEL- 
-39. 200 OK— 



—4. INVITE- 
5. 100 Trying 



HSS 



^6. Cx; User location^ 
\ query / 

^ n . INVITE- 



S-CSCF#2 



-10. INVITE- 

1 1. 100 Trying 

<-- 12.183 - 



-18. PRACK- > 
♦—19. 200 OK 



-24. UPDATE > 
+—25. 200 OK 



*28. 180 Ringing— 




— -34. PRACK- -► 
+—35. 200 OK 



44. GANGEL- 

-45. 200 OK— 



i46. 487 Gancelled- 
47. ACK ► 



-.52. 487 Cancelled- 
53. ACK 



Figure 7.3.2.3-1: Failure in origination procedure 

1-11. INVITE (MO to S-CSCF) et seq 

UE#1 initiated a session, as described in subclause 7.3.2.1. 

12-37. 183 Session Progress (MT to S-CSCF) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.3.2.1. 
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38. CANCEL (MO to S-CSCF) - see example in table 7.3.2.3-38 

The originator, through the MO procedure, cancelled the original INVITE request. 

Table 7.3.2.3-38: CANCEL (MO to S-CSCF) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Route: <sip: scscf 1 .homel . net; lr> 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 CANCEL 
Content-Length: 

39. 200 OK (S-CSCF to S-S) - see example in table 7.3.2.3-39 

Upon receive the CANCEL request from the MO procedure, S-CSCF sends 200 OK. 

Table 7.3.2.3-39: 200 OK (S-CSCF to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 
Call-ID: 

CSeq: 127 CANCEL 
Content-Length: 

40. CANCEL (S-CSCF to I-CSCF) - see example in table 7.3.2.3-40 (related to table 7.3.2.3-38) 

The S-CSCF forwards the CANCEL request to I-CSCF. 

Table 7.3.2.3-40: CANCEL (S-CSCF to I-CSCF) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

41. 200 OK (I-CSCF to S-CSCF) - see example in table 7.3.2.3-41 

Upon receiving the CANCEL request from the S-CSCF, P-CSCF sends 200 OK. 

Table 7.3.2.3-41 : 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 

CSeq: 127 CANCEL 
Content-Length: 

42. CANCEL (I-CSCF to S-CSCF) - see example in table 7.3.2.3-42 (related to table 7.3.2.3-40) 

The I-CSCF forwards the CANCEL request to S-CSCF. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 1 65 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Table 7.3.2.3-42: CANCEL (l-CSCF to S-CSCF) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2„s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Route : <sip: scscf2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

43. 200 OK (S-CSCF to I-CSCF) - see example in table 7.3.2.3-43 

Upon receiving the CANCEL request from the I-CSCF, S-CSCF sends 200 OK. 

Table 7.3.2.3-43: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 

CSeq: 127 CANCEL 
Content-Length: 

44. CANCEL (S-CSCF to MX) - see example in table 7.3.2.3-44 (related to table 7.3.2.3-42) 
The P-CSCF forwards the CANCEL request to the appropriate MT procedure. 

Table 7.3.2.3-44: CANCEL (S-CSCF to MT) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Route : <sip:pcscf2.visited2.net;lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

45. 200 OK (MT to S-CSCF) - see example in table 7.3.2.3-45 

Upon receive the CANCEL request from the S-CSCF, the MT procedure sends 200 OK. 

Table 7.3.2.3-45: 200 OK (MT to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 

CSeq: 127 CANCEL 
Content-Length: 

46. 487 Request Terminated (MT to S-CSCF) - see example in table 7.3.2.3-46 
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The termination procedure detected some error situation, and returned a SIP error response. 
Table 7.3.2.3-46: 487 Request Terminated (MT to S-CSCF) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 
Retry-After: 3600 
Content-Length: 

47. ACK (S-CSCF to MT) - see example in table 7.3.2.3-47 

Upon receive the 487 response from the MT procedure, S-CSCF sends ACK. 

Table 7.3.2.3-47: ACK (S-CSCF to MT) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net ; branch=z9hG4bK764z87 . 1 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 
Call-ID: 
CSeq: 127 ACK 
Content-Length: 

48. 487 Request Terminated (S-CSCF to I-CSCF) - see example in table 7.3.2.3-48 (related to table 7.3.2.3-46) 

The S-CSCF returned a SIP error response to I-CSCF. 

Table 7.3.2.3-48: 487 Request Terminated (S-CSCF to I-CSCF) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP icscf2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

49. ACK (I-CSCF to S-CSCF) - see example in table 7.3.2.3-49 

Upon receive the 487 response from the S-CSCF procedure, I-CSCF sends ACK. 

Table 7.3.2.3-49: ACK (I-CSCF to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Route: <sip : scscf 2 . home2 . net ; lr> 

From: 

To: 
Call-ID: 
CSeq: 127 ACK 
Content-Length: 

50. 487 Request Terminated (I-CSCF to S-CSCF) - see example in table 7.3.2.3-50 (related to table 7.3.2.3-48) 

The I-CSCF returns the SIP error response to S-CSCF. 
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Table 7.3.2.3-50: 487 Request Terminated (l-CSCF to S-CSCF) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 
Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

51. ACK (S-CSCF to I-CSCF) - see example in table 7,3.2.3-51 

Upon receive the 487 response from the S-CSCF procedure, I-CSCF sends ACK. 

Table 7.3.2.3-51 : ACK (S-CSCF to I-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 
CSeq: 127 ACK 
Content-Length: 

52. 487 Request Terminated (S-CSCF to MO) - see example in table 7.3.2.3-52 (related to table 7.3.2.3-50) 

The S-CSCF returns the SIP error response to the appropriate MO procedure. 

Table 7.3.2.3-52: 487 Request Terminated (S-CSCF to MO) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 
Retry-After: 3600 
Content-Length: 

53. ACK (MO to S-CSCF) - see example in table 7.3.2.3-53 

Upon receive the 487 response from the S-CSCF, the MO procedure sends ACK. 

Table 7.3.2.3-53: ACK (IVIO to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Route: <sip: scscf 1 .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



7.3.3 Not applicable 

7.3.4 Not applicable 

7.3.5 S-S#2 
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7.3.5.1 (S-S#2) Single network operator performing origination and termination 

(M0#2, MT#2 assumed) 

Figure 7.3.5.1-1 shows a S-CSCF handling session origination, which performs an analysis of the destination address, 
and determines that it belongs to a subscriber of the same operator. The request is therefore forwarded to a local 1- 
CSCF. The 1-CSCF queries the HSS for current location information, and finds the S-CSCF assigned to the subscriber 
(S-CSCF#2), and forwards the request to S-CSCF#2. 

Origination sequences that share this common S-CSCF to S-CSCF procedure are: 

MO#la Mobile origination, roaming, without a THIG. The "Originating Network" of S-S#2 is therefore a 

visited network. 

MO#lb Mobile origination, roaming, with a THIG in home network. The "Originating Network" of S-S#2 

is therefore a visited network. 

MO#2 Mobile origination, located in home service area. The "Originating Network" of S-S#2 is therefore 

the home network. 

CS-O CS Networks origination. The "Originating Network" of S-S#2 is the home network. The element 

labeled S-CSCF#1 is the MGCF of the CS-O procedure. 

Termination sequences that share this common S-CSCF to S-CSCF procedure are: 

MT#la Mobile termination, roaming, without a THIG. The "Terminating Network" of S-S#2 is a visited 

network. 

MT#lb Mobile termination, roaming, with a THIG in home network. The "Terminating Network" of S- 

S#2 is a visited network. 

MT#2 Mobile termination, located in home service area. The "Terminating Network" of S-S#2 is the 

home network. 
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Figure 7.3.5.1-1 :S-S#2 

Procedure S-S#2 is as follows: 

1 . INVITE (MO to S-S#2) - see example in table 7.3.5.1-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 7.3.5.1-1 : INVITE (MO to S-S#2) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa ; bbb : ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Route: <sip: scscfl .homel . net; lr> 
Record-Route : <sip;pcscfl. homel .net; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e ; d3d: c2c] 
Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 
To; <tel;+l-212-555-2222> 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 127 INVITE 
Require; precondition 
Supported; lOOrel 
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Contact: <sip: [5555: : aaa:bbb: ccc : ddd] > 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa:bbb: ccc: ddd 
s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 
t=907165275 
m=video 340 RTP/AVP 99 
b=AS:54. 6 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap: 99:MPV 
m=video 3402 RTP/AVP 99 
b=AS:54.6 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 
b=AS:25.4 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
a=rtpmap:96 G726-32/8000 
m=audio 3458 RTP/AVP 97 96 15 
b=AS:25.4 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
a=rtpmap:96 G726-32/8000 



2. 100 Trying (S-S#2 to MO) - see example in table 7.3.5.1-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.3.5.1-2: 100 Trying (S-S#2 to MO) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



3. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For this 
example, assume no Application Server involvement. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 7.3.5.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, S-CSCF#1 forwards the INVITE request directly to to I-CSCF in the destination 
network. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 
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Table 7.3.5.1-4: INVITE (S-CSCF to l-CSCF) 

INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: icscf2_s . homel . net ; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

P -As sorted- Identity : 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel . net 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa:bbb: ccc : ddd 
s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 
t=907165275 
m=video RTP/AVP 99 
b=AS:54.6 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 9 9 : MPV 
m=video RTP/AVP 99 
b=AS:54.6 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 9 9 : MPV 

m=audio 3456 RTP/AVP 97 96 15 
b=AS:25.4 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
a=rtpmap:96 G726-32/8000 
m=audio 3458 RTP/AVP 97 96 15 
b=AS:25.4 

a=curr:qos local none 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
a=rtpmap:96 G726-32/8000 

Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP -URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 

5. 100 Trying (I-CSCF to S-CSCF) - see example in table 7.3.5.1-5 

I-CSCF responds to the INVITE request (4) by sending a 100 Trying provisional response to S-CSCF#1. 
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Table 7.3.5.1-5: 100 Trying (l-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
CSeq: 
Content-Length: 

6. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228[1 1]. 

Table 7.3.2. l-6a provides the parameters in the SIP INVITE request (flow 4), which are sent to the HSS. 

Table 7.3.2. l-6b provides the parameters sent from the HSS that need to be mapped to SIP INVITE request 
(flow 7) and sent to S-CSCF. 

7. INVITE (I-CSCF to S-CSCF) - see example in table 7.3.5.1-7 

I-CSCF forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 7.3.5.1-7: INVITE (I-CSCF to S-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .homel . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip: scscf 2 .homel . net ; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

Supported: 

P-Asserted- Identity : 
P-Charging-Vector : 

Privacy : 

From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 

v= 
o = 
s = 
c = 

t = 
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NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

8. 100 Trying (S-CSCF to I-CSCF) - see example in table 7.3.5.1-8 

S-CSCF#2 responds to the INVITE request (8) with a 100 Trying provisional response. 

Table 7.3.5.1-8: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf2_s .homel . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 



9. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. 

10. INVITE (S-S#2 to MT) - see example in table 7.3.5.1-10 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 

S-CSCF#2 examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 

Table 7.3.5.1-10: INVITE (S-S#2 to MT) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 

[5555 : : aaa: bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route: <sip : pcscf 2 . homel . net ; lr> 

Record-Route: <sip : scscf 2 . homel . net ; lr>, <sip : scscf 1 . homel . net ; lr>, <sip : pcscf 1 . homel . net ; lr> 
P -Asserted- Identity : 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
P-Called-Party-ID: <tel:+l-212-555-2222> 
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Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa:bbb: ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a= r tpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



1 1. 100 Trying (MT to S-S#2) - see example in table 7.3.5.1-11 (related to table 7.3.5.1-10) 

S-CSCF#2 receives a 100 Trying provisional response to the INVITE request (11), as specified by the 
termination procedures. 



Table 7.3.5.1-11: 100 Trying (MT to S-S#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . homel . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length: 



12. 183 Session Progress (MT to S-S#2) - see example in table 7.3.5.1-12 (related to table 7.3.5.1-10) 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response, as per the termination procedure. 

Table 7.3.5.1-12: 183 Session Progress (MT to S-S#2) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . homel . net ;branch=z9hG4bK764z87 . 1, 
SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 



SIP/2. 0/UDP icscf2.homel.net, 
SIP/2. 0/UDP 
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Record-Route : <sip:pcscf2 .homel . net; lr>, <sip:scscf2 .homel . net; lr>, <sip:scscfl .homel . net; lr>, 

<sip;pcscfl . homel .net; lr> 
P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy; none 
From; 

To; <tel;+l-212-555-2222>; tag=314159 
Call-ID; 
CSeq: 

Require; lOOrel 

Contact; <sip; [5555; ; eee ; f f f ; aaa;bbb] > 
RSeq; 9021 

Content-Type; application/sdp 
Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ; ; aaa;bbb; ccc ; ddd 
s=- 

c=IN IP6 5555; ;eee;fff ;aaa;bbb 
t=907165275 
m=video RTP/AVP 99 
m=video RTP/AVP 99 
m=audio 6544 RTP/AVP 97 96 
b=AS;25.4 

a=curr;qos local none 
a=curr;qos remote none 
a=des;qos mandatory local sendrecv 
a=des;qos mandatory remote sendrecv 
a=conf:qos remote sendrecv 
a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 
a=rtpmap;96 G726-32/8000 
m=audio RTP/AVP 97 96 15 

13. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 7.3.5.1-13 

S-CSCF#2 forwards the 183 Session Progress provisional response to I-CSCF. 

Table 7.3.5.1-13: 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via; SIP/2. 0/UDP icscf2_s . homel . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; 

P -Asserted- Identity ; 
P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 

P-Charging-Funct ion-Addresses; ccf=[5555; ;b99;c88;d7 7;e66]; ccf=[5555; ;a55;b44;c33;d22]; 
ecf=[5555;;lff;2ee;3dd;4cc]; ecf=[5555; ; 6aa; 7bb; 8cc ; 9dd] 

Privacy ; 

From; 

To; 
Call-ID; 
CSeq; 
Require : 
Contact : 
RSeq: 

Content-Type ; 
Content-Length ; 

v= 
o = 
s = 

c = 

t = 
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P-Charging- Vector: The S-CSCF adds the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 

14. 183 Session Progress (I-CSCF to S-CSCF) - see example in table 7.3.5.1-14 

I-CSCF forwards the 183 Session Progress provisional response to S-CSCF#1. 

Table 7.3.5.1-14: 183 Session Progress (I-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; 

P -Asserted- Identity: 
P-Charging-Vector : 

Privacy ; 

From; 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 
RSeq: 

Content-Type : 
Content-Length : 



15. 183 Session Progress (S-S#2 to MO) - see example in table 7.3.5.1-15 

S-CSCF#1 forwards the 183 Session Progress to the originator, as per the originating procedure. 

Table 7.3.5.1-15: 183 Session Progress (S-S#2 to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscfl . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P -Asserted- Identity: 
P-Charging-Vector : 

Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
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Content-Type : 
Content-Length : 



16. PRACK (MO to S-S#2) - see example in table 7.3.5.1-16 

The originator decides the final set of media streams, and includes this information in the PRACK request 
sent to S-CSCF#1 by the origination procedures. 

Table 7.3.5.1-16: PRACK (MO to S-S#2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel .net; lr>, <sip: scscf 2 .homel . net; lr>, <sip:pcscf 2 .homel . net; lr> 
From: <sip:userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 128 PRACK 
Require: precondition 
Rack: 9021 127 INVITE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



17. PRACK (S-CSCF to S-CSCF) - see example in table 7.3.5.1-17 

S-CSCF#1 forwards the PRACK request to S-CSCF#2. 

Table 7.3.5.1-17: PRACK (S-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .homel . net ; lr>, <sip : pcscf 2 . homel . net ; lr> 
From: 
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To: 

Call-ID: 
Cseq: 
Require : 

Rack: 

Content-Type : 
Content-Length : 



18. PRACK (S-S#2 to MT) - see example in table 7.3.5.1-18 

S-CSCF#2 forwards the PRACK request to the terminating endpoint, as per the termination procedure. 

Table 7.3.5.1-18: PRACK (S-S#2 to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip:pcscf 2 .homel . net ; lr> 

From: 

To: 
Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



19. 200 OK (MT to S-S#2) - see example in table 7.3.5.1-19 (related to table 7.3.5.1-18) 

The terminating endpoint responds to the PRACK request (19) with a 200 OK response. 

Table 7.3.5.1-19: 200 OK (MT to S-S#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2 .0/UDP 
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pcscf 1 .homel . net;branch=z9hG4bK431h23 . 1, SIP/ 2 . 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

C=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



20. 200 OK (S-CSCF to S-CSCF) - see example in table 7.3.5.1-20 

S-CSCF#2 forwards the 200 OK response to S-CSCF#1. 

Table 7.3.5.1-20: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



21. 200 OK (S-S#2 to MO) - see example in table 7.3.5.1-21 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.5.1-21 : 200 OK (S-S#2 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
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CSeq: 

Content-Type : 
Content-Length ; 



22. UPDATE (MO to S-S#2) - see example in table 7.3.5.1-22 

When the originating endpoint has completed the resource reservation procedures, it sends the UPDATE 
request to S-CSCF#1 by the origination procedures. 

Table 7.3.5.1-22: UPDATE (MO to S-S#2) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel .net; lr>, <sip: scscf 2 .homel . net; lr>, <sip:pcscf 2 .homel . net; lr> 
From: <sip:userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 12 9 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



23. UPDATE (S-CSCF to S-CSCF) - see example in table 7.3.5.1-23 

S-CSCF#1 forwards the UPDATE request to S-CSCF#2. 

Table 7.3.5.1-23: UPDATE (S-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip : scscf 2 . homel . net ; lr>, <sip : pcscf 2 . homel . net ; lr> 
From: 
To: 
Call-ID: 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



181 



ETSI TS 124 228 V5.3.0 (2002-12) 



Cseq: 

Content-Type : 
Content-Length ; 



24. UPDATE (S-S#2 to MT) - see example in table 7.3.5.1-24 

S-CSCF#2 forwards the UPDATE request to the terminating endpoint, as per the termination procedure. 

Table 7.3.5.1-24: UPDATE (S-S#2 to MT) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route: <sip:pcscf 2 .homel . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Type : 
Content-Length : 



25. 200 OK (MT to S-S#2) - see example in table 7.3.5.1-25 (related to table 7.3.5.1-24) 

The terminating endpoint responds to the UPDATE request (24) with a 200 OK response. 

Table 7.3.5.1-25: 200 OK (MT to S-S#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 

[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Type : 
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Content-Length : 



v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



26. 200 OK (S-CSCF to S-CSCF) - see example in table 7.3.5.1-26 

S-CSCF#2 forwards the 200 OK response to S-CSCF#1. 

Table 7.3.5.1-26: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



27. 200 OK (S-S#2 to MO) - see example in table 7.3.5.1-27 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.5.1-27: 200 OK (S-S#2 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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28. 180 Ringing (MT to S-S#2) - see example in table 7.3.5.1-28 (related to table 7.3.5.1-10) 

The terminating endpoint may optionally send a 180 Ringing provisional response indicating alerting is in 
progress. This response is sent by the termination procedure to S-CSCF#2. 

Table 7.3.5.1-28: 180 Ringing (MT to S-S#2) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route; <sip;pcscf 2 .homel . net; lr>, <sip ; scscf 2 . homel . net ; lr>, <sip; scscf 1 .homel . net; lr>, 

<sip;pcscfl . homel .net; lr> 
From; 
To; 

Call-ID; 
CSeq: 

Require; lOOrel 
Contact; <sip; [5555; ; eee ; f f f ; aaa;bbb] > 

RSeq; 9022 

Content-Length; 



29. 180 Ringing (S-CSCF to I-CSCF) - see example in table 7.3.5.1-29 

S-CSCF#2 forwards the 180 Ringing response to I-CSCF. 

Table 7.3.5.1-29: 180 Ringing (S-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via; SIP/2. 0/UDP icscf 2_s .homel . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route ; 
From; 
To; 

Call-ID; 
CSeq; 
Require : 
Contact ; 
RSeq; 
Content-Length ; 



30. 180 Ringing (I-CSCF to S-CSCF) - see example in table 7.3.5.1-30 

I-CSCF forwards the 180 Ringing response to S-CSCF#1. 

Table 7.3.5.1-30: 180 Ringing (I-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via; SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa; bbb; ccc; ddd] ;branch=z9hG4bKnashds7 
Record-Route ; 
From; 
To; 

Call-ID; 
CSeq; 
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Require : 
Contact : 
RSeq: 
Content-Length : 



31. 180 Ringing (S-S#2 to MO) - see example in table 7.3.5.1-31 

S-CSCF#1 forwards the 180 Ringing response to the originator, per the origination procedure. 

Table 7.3.5.1-31 : 180 Ringing (S-S#2 to MO) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; : aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From; 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

32. PRACK (MO to S-S#2) - see example in table 7.3.5.1-32 

The originator acknowledges the 180 Ringing provisional response (34) with a PRACK request. 

Table 7.3.5.1-32: PRACK (MO to S-S#2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel . net; lr>, <sip: scscf 2 .homel . net; lr>, <sip:pcscf2 .homel . net; lr>. 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 

33. PRACK (S-CSCF to S-CSCF) - see example in table 7.3.5.1-33 

S-CSCF#1 forwards the PRACK request to S-CSCF#2. 

Table 7.3.5.1-33: PRACK (S-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: scscf 2 .homel . net ; lr>, <sip : pcscf 2 . homel . net ; lr> 

From: 

To: 

Call-ID: 

Cseq: 
Rack: 
Content-Length : 

34. PRACK (S-S#2 to MX) - see example in table 7.3.5.1-34 

S-CSCF#2 forwards the PRACK request to the terminating endpoint. 

Table 7.3.5.1-34: PRACK (S-S#2 to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards ; 67 
Route: <sip:pcscf2 .homel . net> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

35. 200 OK (MT to S-S#2) - see example in table 7.3.5.1-35 (related to table 7.3.5.1-34) 

The terminating endpoint responds to the PRACK request (34) with a 200 OK response. 

Table 7.3.5.1-35: 200 OK (MT to S-S#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

36. 200 OK (S-CSCF to S-CSCF) - see example in table 7.3.5.1-36 

S-CSCF#2 forwards the 200 OK response to S-CSCF#1. 

Table 7.3.5.1-36: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 

CSeq: 

Content-Length : 

37. 200 OK (S-S#2 to MO) - see example in table 7.3.5.1-37 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.5.1-37: 200 OK (S-S#2 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 
CSeq: 
Content-Length : 
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38. 200 OK (MT to S-S#2) - see example in table 7.3.5.1-38 (related to table 7.3.5.1-10) 

The final response, 200 OK, is sent by the terminating endpoint over the signalHng path. This is typically 
generated when the subscriber has accepted the incoming session attempt. The response is sent to S-CSCF#2 
per the termination procedure. 

Table 7.3.5.1-38: 200 OK (MT to S-S#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route; <sip;pcscf 2 .homel . net ; lr>, <sip; scscf 2 .homel . net; lr>, <sip: scscf 1 .homel . net; lr>, 

<sip; pcscfl . homel .net; lr> 
From; 
To; 

Call-ID; 
CSeq; 127 INVITE 

Contact; <sip; [5555; ; eee ; f f f ; aaa;bbb] > 
Content-Length; 

39. 200 OK (S-CSCF to I-CSCF) - see example in table 7.3.5.1-39 

The 200 OK response is forwarded to the I-CSCF. 

Table 7.3.5.1-39: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP icscf 2_s .homel . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa; bbb; ccc; ddd] ;branch=z9hG4bKnashds7 
Record-Route ; 
From; 
To; 

Call-ID; 
CSeq; 
Contact ; 
Content-Length ; 

40. 200 OK (I-CSCF to S-CSCF) - see example in table 7.3.5.1-40 

The 200 OK response is forwarded to S-CSCF#1. 

Table 7.3.5.1-40: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; 

From; 

To; 
Call-ID; 
CSeq; 
Contact ; 
Content-Length ; 

41. 200 OK (S-S#2 to MO) - see example in table 7.3.5.1-41 

The 200 OK response is returned to the originating endpoint, by the origination procedure. 

Table 7.3.5.1-41 : 200 OK (S-S#2 to MO) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 

[5555 ; ; aaa; bbb; ccc; ddd] ;branch=z9hG4bKnashds7 
Record-Route ; 
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From: 
To: 

Call-ID: 
CSeq: 

Contact : 
Content-Length : 



42. ACK (MO to S-S#2) - see example in table 7.3.5.1-42 

The originating endpoint sends the final acknowledgement to S-CSCF#1 by the origination procedures. 

Table 7.3.5.1-42: ACK (MO to S-S#2) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 69 

Route: <sip: scscfl .homel . net; lr>, <sip: scscf 2 .homel . net; lr>, <sip:pcscf 2 .homel . net; lr> 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 ACK 
Content-Length: 

43. ACK (S-CSCF to S-CSCF) - see example in table 7.3.5.1-43 

S-CSCF#1 forwards the ACK request to S-CSCF#2. 

Table 7.3.5.1-43: ACK (S-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scsf 2 .homel . net; lr>, <sip:pcscf 2 .homel . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

44. ACK (S-S#2 to MX) - see example in table 7.3.5.1-44 

S-CSCF#2 forwards the ACK request to the terminating endpoint, as per the termination procedure. 

Table 7.3.5.1-44: ACK (S-S#2 to MT) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route: <sip:pcscf 2 .homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

7.3.5.2 (S-S#2) Single network operator performing origination and termination, 

terminating UE is busy, and not able or not willing to answer the call (M0#2, 
MT#2 assumed) 

Figure 7.3.5.2-1 shows the subscriber that originated a session with one of the MO procedures had the attempt fail due 
to an error detected in the termination procedure. In this flow, 486 error response is shown as the example. 
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Figure 7.3.5.2: (S-S#2) Single network operator performing origination and termination, 
terminating UE is busy, and not able or not willing to answer the call (M0#2, MT#2 assumed) 

1-10. The same as described in flow 1-8 in subclause 7.3.5 

1 1. 486 Busy Here (MT to S-CSCF) - see example in table 7.3.5.2-11 

The termination procedure detected some error situation, and returned a SIP 486 Busy Here response. 

NOTE: The error response may be other error responses like "403 Service Denied", "480 Temporarily 
Unavailable", "580 Precondition Failure", or others. For this example, "486 Busy" is shown. 



Table 7.3.5.2-11 : 486 Busy Here (MT to S-CSCF) 



SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7) 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:-H-212-555-2222>;tag=31415 9 

Contact: <sip: [5555: : eee : f f f : aaa : bbb] > 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 
Retry-After: 3600 
Content-Length: 



12. ACK (S-CSCF to MT) - see example in table 7.3.5.2-12 

Upon receive the 486 response from the MT procedure, S-CSCF sends ACK. 
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Table 7.3.5.2-12: ACK (S-CSCF to MT) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP sip : scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1 

Max-Forwards: 70 

Route: <sip:pcscf2 .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

13. 486 Busy Here (S-CSCF to I-CSCF) - see example in table 7.3.5.2-13 

The S-CSCF returned a SIP error response to I-CSCF. 

Table 7.3.5.2-13: 486 Busy Here (S-CSCF to I-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP icscf2_s . homel . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscfl .homel . net; branch=z9hG4bK4 31h23 .1, SIP/2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7) 
From: 
To: 
Call-ID: 
CSeq: 

Contact: <sip: [5555: : eee : f f f : aaa :bbb] > 
Retry-After: 3600 
Content-Length: 

14. ACK (I-CSCF to S-CSCF) - see example in table 7.3.5.2-14 

Upon receive the 486 response from the S-CSCF procedure, I-CSCF sends ACK. 

Table 7.3.5.2-14: ACK (I-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s . homel . net ; branch=z9hG4bK871yl2 . 1 

Max-Forwards: 70 

Route : <sip: scscf2 .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

15. 486 Busy Here (I-CSCF to S-CSCF) - see example in table 7.3.5.2-15 (related to table 7.3.5.2-42) 
The I-CSCF returned a SIP error response to S-CSCF. 

Table 7.3.5.2-15: 486 Busy Here (I-CSCF to S-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7) 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Retry-After: 3600 

Content-Length: 

16. ACK (S-CSCF to I-CSCF) - see example in table 7.3.5.2-16 

Upon receive the 486 response from the S-CSCF procedure, I-CSCF sends ACK. 
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Table 7.3.5.2-16: ACK (S-CSCF to l-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route : <sip : icscf 2_s . homel . net ; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

17. 486 Busy Here (S-CSCF to MO) - see example in table 7.3.5.2-17 

The S-CSCF returned a SIP error response to the appropriate MO procedure. 

Table 7.3.5.2-17: 486 Busy Here (S-CSCF to MO) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscfl . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7) 
From: 
To: 

Contact : 
Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

18. ACK (MO to S-CSCF) - see example in table 7.3.5.2-18 

Upon receiving the 486 response from the S-CSCF, the MO procedure sends ACK. 

Table 7.3.5.2-18: ACK (MO to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route : <sip:scscfl .homel . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



7.3.5.3 Origination failure (not provided) 

An example of this flow is not shown in the present document. 

7.3.6 S-S#3 

7.3.6.1 (S-S#3) PSTN Termination performed by home network of originator (M0#2 

assumed) 

Figure 7.3.6.1-1 shows a S-CSCF handling session origination, which performs an analysis of the destination address, 
and determines that it will result in a PSTN termination. The request is therefore forwarded to a local BGCF. The 
BGCF performs further analysis of the destination address, combined with information of agreements between 
operators for optimum Gateway selection, and decides to do the PSTN termination locally. The BGCF therefore 
allocates a MGCF within the home network, and sends the request to it. This example flow does not show Application 
Server involvement. 

Origination sequences that share this common S-CSCF to S-CSCF procedure are: 

MO#la Mobile origination, roaming, without a THIG. The "Originating Network" of S-S#3 is therefore a 

visited network. 
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MO#lb Mobile origination, roaming, with a THIG in home network. The "Originating Network" of S-S#3 

is therefore a visited network. 

MO#2 Mobile origination, located in home service area. The "Originating Network" of S-S#3 is therefore 

the home network. 

CS-O CS Networks origination. The "Originating Network" of S-S#3 is the home network. The element 

labelled S-CSCF#1 is the MGCF of the CS-O procedure. 

Termination sequences that share this common S-CSCF to S-CSCF procedure are: 

CS-T CS Networks termination. 
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Procedure S-S#3 is as follows: 
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1 . INVITE (MO to S-S#3) - see example in table 7.3.6.1-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 7.3.6.1-1 : INVITE (MO to S-S#3) 

INVITE sip: +l-212-555-2222@homel . net ; user=phone SIP/2.0 
Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel . net; lr> 
Record-Route : <sip:pcscfl. homel .net; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 
Require: precondition 
Supported: lOOrel 

Contact: <sip: [5555: : aaa: bbb: ccc : ddd] > 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video 3402 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

2. 100 Trying (S-S#3 to MO) - see example in table 7.3.6.1-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.3.6.1-2: 100 Trying (S-S#3 to MO) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
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CSeq: 

Content-Length: 



3. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For this 
example, assume no Application Server involvement. 

4. INVITE (S-CSCF to BGCF) - see example in table 7.3.6.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the destination is on the PSTN. S- 
CSCF forwards the INVITE request to the BGCF in the local network. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 



Table 7.3.6.1-4: INVITE (S-CSCF to BGCF) 



INVITE sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip:bgcfl .homel . net; lr> 

Record-Route : <sip:scscfl. homel .net;lr>^ <sip:pcscfl. homel .net; lr> 

P -As sorted- Identity: 

P-Charging-Vector : 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc: 9dd] 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 
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a=fmtp:97 mode-set=0, 2, 5, 7; maxf rames=2 
a=rtpmap:96 G726-32/8000 

Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP-URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

P-Charging- Vector: The S-CSCF passes this header to the BGCF for charging. 

P-Charging-Function-Addresses: The S-CSCF inserts this header to provide the charging function addresses to the 
BGCF. 

5. 100 Trying (BGCF to S-CSCF) - see example in table 7.3.6.1-5 

BGCF sends a 100 Trying provisional response to S-CSCF. 

Table 7.3.6.1-5: 100 Trying (BGCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

6. INVITE (BGCF to MGCF) - see example in table 7.3.6.1-6 

BGCF analyzes the destination address, and allocates a MGCF to handle the termination. BGCF forwards the 
INVITE request to the MGCF. 

Table 7.3.6.1-6: INVITE (BGCF to MGCF) 

INVITE sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP bgcfl .homel .net;branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip:mgcfl .homel . net; lr> 

Record-Route : 

P -Asserted- Identity : 

P-Charging-Vector : 

P-Charging-Function-Addresses : 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 

a= 
a= 
a= 
a= 
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NOTE: The BGCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

7. 100 Trying (MGCF to BGCF) - see example in table 7.3.6.1-7 

MGCF responds to the INVITE request (6) with a 100 Trying provisional response. 

Table 7.3.6.1-7: 100 Trying (MGCF to BGCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP bgcf 1 . homel . net ; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net;branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. 183 Session Progress (MGCF to BGCF) - see example in table 7.3.6.1-8 

The MGCF returns the media stream capabilities of the destination along the signalling path in a 183 Session 
Progress provisional response. 

Table 7.3.6.1-8: 183 Session Progress (MGCF to BGCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP bgcf 1 . homel . net ; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscfl .homel . net; branch=z9hG4bK4 3 lh2 3 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; term- 

ioi=home2 . net 

Privacy: none 

From: 

To: <tel:+l-212-555-2222>; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: <sip:mgcfl .homel . net> 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 
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t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 



9. 183 Session Progress (BGCF to S-CSCF) - see example in table 7.3.6.1-9 
BGCF forwards the 183 Session Progress provisional response to S-CSCF. 

Table 7.3.6.1-9: 183 Session Progress (BGCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted- Identity : 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



10. 183 Session Progress (S-S#3 to MO) - see example in table 7.3.6.1-10 

S-CSCF#1 forwards the 183 Session Progress to the originator, as per the originating procedure. 

Table 7.3.6.1-10: 183 Session Progress (S-S#3 to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscfl .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
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Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length ; 



1 1. PRACK (MO to S-S#3) - see example in table 7.3.6.1-11 

The originator decides the final set of media streams, and includes this information in the PRACK request 
sent to S-CSCF#1 by the origination procedures. 

Table 7.3.6.1-11 : PRACK (MO to S-S#3) 

PRACK sip:mgcfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Route; <sip; scscfl .homel . net; lr> 
From; <sip ; userl_publicl@homel . net>; tag=171828 
To; <tel;+l-212-555-2222>; tag=314159 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 128 PRACK 
Require; precondition 
Rack; 9021 127 INVITE 
Content-Type; application/sdp 
Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ;bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos mandatory remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

12. PRACK (S-CSCF to MGCF) - see example in table 7.3.6.1-12 

S-CSCF forwards the PRACK request to MGCF. 

Table 7.3.6.1-12: PRACK (S-CSCF to MGCF) 

PRACK sip;mgcfl. homel. net SIP/2.0 

Via; SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 
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From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



13. 200 OK (MGCF to S-CSCF) - see example in table 7.3.6.1-13 

The MGCF responds to the PRACK request (12) with a 200 OK response. 

Table 7.3.6.1-13: 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



14. 200 OK (S-S#3 to MO) - see example in table 7.3.6.1-14 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.6.1-14: 200 OK (S-S#3 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
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Content-Type : 
Content-Length : 



15. UPDATE (MO to S-S#3) - see example in table 7.3.6.1-15 

When the originating endpoint has completed the resource reservation procedures, it sends the UPDATE 
request to S-CSCF#1 by the origination procedures. 

Table 7.3.6.1-15: UPDATE (MO to S-S#3) 

UPDATE sip:mgcfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Route: <sip: scscfl .homel . net; lr> 

P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 129 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

P-Charging- Vector: The P-CSCF added the GPRS access network information to this header, which is removed 
and stored by the S-CSCF. 

Upon receiving the UPDATE, the S-CSCF stores the P-Charging-Vector information for use in charging. 

16. UPDATE (S-CSCF to MGCP) - see example in table 7.3.6.1-16 

S-CSCF forwards the UPDATE request to MGCF. 

Table 7.3.6.1-16: UPDATE (S-CSCF to MGCF) 

UPDATE sip:mgcfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 
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Max-Forwards: 68 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



17. 200 OK (MGCF to S-CSCF) - see example in table 7.3.6.1-17 

The MGCF responds to the UPDATE request (16) with a 200 OK response. 

Table 7.3.6.1-17: 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audlo RTP/AVP 97 96 15 

18. 200 OK (S-S#3 to MO) - see example in table 7.3.6.1-18 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.6.1-18: 200 OK (S-S#3 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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19. 180 Ringing (MGCF to BGCF) - see example in table 7.3.6.1-19 

The MGCF may optionally send a 180 Ringing provisional response indicating alerting is in progress. This 
response is sent by the termination procedure to BGCF. 

Table 7.3.6.1-19: 180 Ringing (MGCF to BGCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP bgcf 1 . homel . net ; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Require: lOOrel 

Contact: <sip:mgcfl .homel . net> 

RSeq: 9022 

Content-Length: 

20. 180 Ringing (BGCF to S-CSCF) - see example in table 7.3.6.1-20 

BGCF forwards the 180 Ringing response to S-CSCF. 

Table 7.3.6.1-20: 180 Ringing (BGCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

21. 180 Ringing (S-S#3 to MO) - see example in table 7.3.6.1-21 

S-CSCF forwards the 180 Ringing response to the originator, per the origination procedure. 

Table 7.3.6.1-21 : 180 Ringing (S-S#3 to MO) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 
Call-ID: 
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CSeq: 
Require : 
Contact : 
RSeq: 

Content-Length : 



22. PRACK (MO to S-S#3) - see example in table 7.3.6.1-22 

The originator acknowledges the 180 Ringing provisional response (21) with a PRACK request. 

Table 7.3.6.1-22: PRACK (MO to S-S#3) 

PRACK sip:mgcfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route; <sip; scscfl .homel . net; lr> 
From: <sip ; userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=314159 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 

23. PRACK (S-CSCF to MGCF) - see example in table 7.3.6.1-23 

S-CSCF forwards the PRACK request to MGCF. 

Table 7.3.6.1-23: PRACK (S-CSCF to MGCF) 

PRACK sip:mgcfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

24. 200 OK (MGCF to S-CSCF) - see example in table 7.3.6.1-24 

The MGCF responds to the PRACK request (23) with a 200 OK response. 

Table 7.3.6.1-24: 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

25. 200 OK (S-S#3 to MO) - see example in table 7.3.6.1-25 

S-CSCF forwards the 200 OK response to the originating endpoint. 

Table 7.3.6.1-25: 200 OK (S-S#3 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
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Content-Length : 

26. 200 OK (MGCF to BGCF) - see example in table 7.3.6.1-26 

The final response, 200 OK, is sent by the MGCF over the signalling path when the subscriber has accepted 
the incoming session attempt. 

Table 7.3.6.1-26: 200 OK (MGCF to BGCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP bgcf 1 . homel . net ; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip:mgcfl .homel . net> 

Content-Length: 

27. 200 OK (BGCF to S-CSCF) - see example in table 7.3.6.1-27 

The 200 OK response is forwarded to the S-CSCF. 

Table 7.3.6.1-27: 200 OK (BGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

28. 200 OK (S-S#3 to MO) - see example in table 7.3.6.1-28 

The 200 OK is returned to the originating endpoint, by the origination procedure. 

Table 7.3.6.1-28: 200 OK (S-S#3 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

29. ACK (MO to S-S#3) - see example in table 7.3.6.1-29 

The originating endpoint sends the final acknowledgement to S-CSCF#1 by the origination procedures. 

Table 7.3.6.1-29: ACK (MO to S-S#3) 

ACK sip:mgcfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
Route: <sip: scsfl .homel . net; lr> 

From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: cb03a0s0 9a2sdf gilt j 4 90333 
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Cseq: 127 ACK 
Content-Length: 



30. ACK (S-CSCF to MGCF) - see example in table 7.3.6.1-30 

S-CSCF#1 forwards the ACK request to MGCF. 

Table 7.3.6.1-30: ACK (S-CSCF to MGCF) 

ACK sip:mgcfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



7.3.7 S-S#4 

7.3.7.1 (S-S#4) PSTN Termination performed by different operator than origination 

(M0#2 assumed) 

Figure 7.3.7. 1-1 shows a S-CSCF handling session origination, which performs an analysis of the destination address, 
and determines that it will result in a PSTN termination. The request is therefore forwarded to a local BGCF (BGCF#1). 
BGCF#1 performs further analysis of the destination address, combined with information of agreements between 
operators for optimum Gateway selection, and decides to do the PSTN termination in a different operator's network. 
BGCF#1 therefore forwards the request to a BGCF in the terminating operator's network, BGCF#2. BGCF#2 allocates a 
MGCF within the its network, and sends the request to it. This example flow does not show Application Server 
involvement. 

Origination sequences that share this common S-CSCF to S-CSCF procedure are: 

MO#la Mobile origination, roaming, without a THIG. The "Originating Network" of S-S#4 is therefore a 

visited network. 

MO#lb Mobile origination, roaming, with a THIG in home network. The "Originating Network" of S-S#4 

is therefore a visited network. 

MO#2 Mobile origination, located in home service area. The "Originating Network" of S-S#4 is therefore 

the home network. 

CS-O CS Networks origination. The "Originating Network" of S-S#4 is the home network. The element 

labeled S-CSCF#1 is the MGCF of the CS-O procedure. 

Termination sequences that share this common S-CSCF to S-CSCF procedure are: 

CS-T CS Networks termination. 
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Figure 7.3.7.1-1 :S-S#4 

Procedure S-S#4 is as follows: 

1 . INVITE (MO to S-S#4) - see example in table 7.3.7.1-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 7.3.7.1-1 : INVITE (MO to S-S#4) 

INVITE sip:-H-212-555-2222@homel.net; user=phone SIP/2.0 
Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Route; <sip ; scscfl . homel . net ; lr> 
Record-Route ; <sip;pcscfl. homel .net; lr> 
P-Asserted-Identity; "John Doe" <tel ; -H-212-555-llll> 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; dSd; c2c] 
Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 
To; <tel;-H-212-555-2222> 
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Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require; precondition 

Supported: lOOrel 

Contact: <sip: [5555: : aaa:bbb: ccc : ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 
o= 



2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 



c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video 34 02 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



2. 100 Trying (S-S#4 to MO) - see example in table 7.3.7.1-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.3.7.1-2: 100 Trying (S-S#4 to MO) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

3. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For this 
example, assume no Application Server involvement. 

4. INVITE (S-CSCF to BGCF) - see example in table 7.3.7.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the destination is on the PSTN. S- 
CSCF#1 forwards the INVITE request to the BGCF in the local network. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 207 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Table 7.3.7.1-4: INVITE (S-CSCF to BGCF) 

INVITE sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip:bgcfl .homel . net; lr> 

Record-Route : <sip:scscfl .homel . net; lr>, <sip:pcscfl .homel . net; lr> 

P -Asserted- Identity : 

P-Charging-Vector : 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc: 9dd] 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

P-Charging- Vector: The S-CSCF passes this header to the BGCF for charging. 

P-Charging-Function- Addresses: The S-CSCF inserts this header to provide the charging function addresses to the 
BGCF. 

5. 100 Trying (BGCF to S-CSCF) - see example in table 7.3.7.1-5 

BGCF#1 sends a 100 Trying provisional response to S-CSCF#1. 

Table 7.3.7.1-5: 100 Trying (BGCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



6. INVITE (BGCF to BGCF) - see example in table 7.3.7.1-6 

BGCF#1 analyses the destination address, and the inter-operator agreements for optimal PSTN termination, 
and selects the network operator that can best terminate this session. BGCF#1 forwards the INVITE request 
to the BGCF (BGCF#2) in the network that will handle the session termination. 

Table 7.3.7.1-6: INVITE (BGCF to BGCF) 

INVITE sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP bgcf 1 .homel .net;branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip:bgcf 2 .home2 . net; lr> 

Record-Route : 

P -As sorted- Identity : 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



7. 100 Trying (BGCF to BGCF) - see example in table 7.3.7.1-7 
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BGCF#2 responds to the INVITE request (6) with a 100 Trying provisional response. 
Table 7.3.7.1-7: 100 Trying (BGCF to BGCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP bgcf 1 . homel . net ;branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. INVITE (BGCF to MGCF) - see example in table 7.3.7.1-8 

BGCF#2 allocates a Media Gateway Controller, and forwards the INVITE request to that MGCF. 

Table 7.3.7.1-8: INVITE (BGCF to MGCF) 

INVITE sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 
Via: SIP/2. 0/UDP bgcf 2 . home2 . net ; branch=z9hG4bK456u71 . 1, SIP/2. 0/UDP 

bgcf 1. homel. net ;branch=z9hG4bK65 4 6q2. 1, S IP /2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: <sip:mgcf 2 .home2 . net; lr> 
Record-Route : 
P -Asserted- Identity : 
P-Charging-Vector : 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 
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9. 100 Trying (MGCF to BGCF) - see example in table 7.3.7.1-9 

MGCF sends a 100 Trying provisional response. 

Table 7.3.7.1-9: 100 Trying (MGCF to BGCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP bgcf 2 .home2 . net; branch=z9hG4bK456u71 . 1, SIP/2. 0/UDP 

bgcf 1 .homel . net; branch=z9hG4bK654 6q2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP /2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

10. 183 Session Progress (MGCF to BGCF) - see example in table 7.3.7.1-10 

MGCF returns the media stream capabilities of the destination in a 183 Session Progress provisional 
response. 

Table 7.3.7.1-10: 183 Session Progress (MGCF to BGCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP bgcf 2 . home2 . net ; branch=z9hG4bK456u71 . 1, SIP/2. 0/UDP 

bgcf 1 .homel . net; branch=z9hG4bK654 6q2 .1, SIP/2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: <sip: scscf 1 .homel . net; lr>, <sip:pcscfl .homel . net; lr> 
P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; term- 
ioi=home2 . net 
Privacy: none 
From: 

To: <tel:+l-212-555-2222>; tag=314159 
Call-ID: 
CSeq: 

Require: lOOrel 

Contact: <sip:mgcf 2 .home2 . net> 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 



v=0 

o=- 2987933615 2987933615 



IN IP6 5555: :aaa:bbb:ccc:ddd 



c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 



1 1. 183 Session Progress (BGCF to BGCF) - see example in table 7.3.7.1-11 

BGCF#2 forwards the 183 Session Progress provisional response to BGCF#1. 
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Table 7.3.7.1-11 : 183 Session Progress (BGCF to BGCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP bgcf 1 .homel . net; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net;branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

P -Asserted- Identity : 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



12. 183 Session Progress (BGCF to S-CSCF) - see example in table 7.3.7.1-12 

BGCF#1 forwards the 183 Session Progress provisional response to S-CSCF. 

Table 7.3.7.1-12: 183 Session Progress (BGCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

P -Asserted- Identity : 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c = 

t = 
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13. 183 Session Progress (S-S#4 to MO) - see example in table 7,3,7,1-13 

S-CSCF#1 forwards the 183 Session Progress response to the originator, as per the originating procedure. 

Table 7.3.7.1-13: 183 Session Progress (S-S#4 to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity: 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 : ; f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



14. PRACK (MO to S-S#4) - see example in table 7.3.7,1-14 

The originator decides the final set of media streams, and includes this information in the PRACK request 
sent to S-CSCF by the origination procedures. 

Table 7.3.7.1-14: PRACK (MO to S-S#4) 

PRACK sip:mgcf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 128 PRACK 
Require: precondition 
Rack: 9021 127 INVITE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 
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m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



15. PRACK (S-CSCF to MGCF) - see example in table 7.3.7.1-15 

S-CSCF forwards the PRACK request to the MGCF. 

Table 7.3.7.1-15: PRACK (S-CSCF to MGCF) 

PRACK sip:mgcf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



16. 200 OK (MGCF to S-CSCF) - see example in table 7.3.7.1-16 

The MGCF responds to the PRACK request (15) with a 200 OK response. 

Table 7.3.7.1-16: 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

C=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 
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a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



17. 200 OK (S-S#4 to MO) - see example in table 7.3.7.1-17 

S-CSCF forwards the 200 OK response to the originating endpoint. 

Table 7.3.7.1-17: 200 OK (S-S#4 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb : ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



18. UPDATE (MO to S-S#4) - see example in table 7.3.7.1-18 

When the originating endpoint has completed the resource reservation procedures, it sends the UPDATE 
request to S-CSCF#1 by the origination procedures. 

Table 7.3.7.1-18: UPDATE (MO to S-S#4) 

UPDATE sip:mgcf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel . net; lr> 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 129 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 
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a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



P-Charging- Vector: The P-CSCF added the GPRS access network information to this header, which is removed 
and stored by the S-CSCF. 

Upon receiving the UPDATE, the S-CSCF stores the P-Charging- Vector information for use in charging. 

19. UPDATE (S-CSCF to MGCF) - see example in table 7.3.7.1-19 

S-CSCF forwards the UPDATE request to the MGCF. 

Table 7.3.7.1-19: UPDATE (S-CSCF to MGCF) 

UPDATE sip:mgcf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



20. 200 OK (MGCF to S-CSCF) - see example in table 7.3.7.1-20 

The MGCF responds to the UPDATE request (19) with a 200 OK response. 

Table 7.3.7.1-20: 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 
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a=conf:qos remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxf rames=2 
m=audio RTP/AVP 97 96 15 



21. 200 OK (S-S#4 to MO) - see example in table 7.3.7.1-21 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 7.3.7.1-21 : 200 OK (S-S#4 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



22. 180 Ringing (MGCF to BGCF) - see example in table 7.3.7.1-22 

The MGCF may optionally send a 180 Ringing provisional response indicating alerting is in progress. 

Table 7.3.7.1-22: 180 Ringing (MGCF to BGCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP bgcf2 .home2 . net; branch=z9hG4bK456u71 . 1, SIP/2. 0/UDP 

bgcfl .homel . net; branch=z9hG4bK654 6q2 .1, SIP/2 .0/UDP scscfl .homel . net;branch=z9hG4bK332b23 . 1, 
SIP /2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 
Require: lOOrel 

Contact: <sip:mgcf 2 .home2 . net> 
RSeq: 9022 
Content-Length: 

23. 180 Ringing (BGCF to BGCF) - see example in table 7.3.7.1-23 
BGCF#2 forwards the 180 Ringing response to BGCF#1. 

Table 7.3.7.1-23: 180 Ringing (BGCF to BGCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP bgcfl . homel . net ; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 
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From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 



24. 180 Ringing (BGCF to S-CSCF) - see example in table 7.3.7.1-24 

BGCF#1 forwards the 180 Ringing response to S-CSCF. 

Table 7.3.7.1-24: 180 Ringing (BGCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

25. 180 Ringing (S-S#4 to MO) - see example in table 7.3.7.1-25 

S-CSCF#1 forwards the 180 Ringing response to the originator, per the origination procedure. 

Table 7.3.7.1-25: 180 Ringing (S-S#4 to MO) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscfl . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

26. PRACK (MO to S-S#4) - see example in table 7.3.7.1-26 

The originator acknowledges the 180 Ringing provisional response (25) with a PRACK request. 

Table 7.3.7.1-26: PRACK (MO to S-S#4) 

PRACK sip:mgcf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 



27. PRACK (S-CSCF to MGCF) - see example in table 7.3.7.1-27 
S-CSCF forwards the PRACK request to the MGCF. 
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Table 7.3.7.1-27: PRACK (S-CSCF to MGCF) 

PRACK sip:mgcf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

28. 200 OK (MGCF to S-CSCF) - see example in table 7.3.7.1-28 

The MGCF responds to the PRACK request (27) with a 200 OK response. 

Table 7.3.7.1-28: 200 OK (MGCF to S-SCSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP pcscfl.home2.net, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

29. 200 OK (S-S#4 to MO) - see example in table 7.3.7.1-29 

S-CSCF forwards the 200 OK to the originating endpoint. 

Table 7.3.7.1-29: 200 OK (S-S#4 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

30. 200 OK (MGCF to BGCF) - see example in table 7.3.7.1-30 

The final response, 200 OK, is sent by the MGCF when the subscriber has accepted the incoming session 
attempt. 

Table 7.3.7.1-30: 200 OK (MGCF to BGCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip :mgcf 2 . home2 . net> 

Content-Length: 

31. 200 OK (BGCF to BGCF) - see example in table 7.3.7.1-31 

BGCF#2 forwards the 200 OK final response to BGCF#1. 

Table 7.3.7.1-31 : 200 OK (BGCF to BGCF) 

SIP/2.0 200 OK 
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Via: SIP/2. 0/UDP bgcfl .home .net, •branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

32. 200 OK (BGCF to S-CSCF) - see example in table 7.3.7.1-32 
BGCF#1 forwards the 200 OK final response to S-CSCF. 

Table 7.3.7.1-32: 200 OK (BGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

33. 200 OK (S-S#4 to MO) - see example in table 7.3.7.1-33 

The 200 OK response is returned to the originating endpoint, by the origination procedure. 

Table 7.3.7.1-33: 200 OK (S-S#4 to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

34. ACK (MO to S-S#4) - see example in table 7.3.7.1-34 

The originating endpoint sends the final acknowledgement to S-CSCF by the origination procedures. 

Table 7.3.7.1-34: ACK (MO to S-S#4) 

ACK sip:mgcf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 ACK 
Content-Length: 

35. ACK (S-CSCF to MGCF) - see example in table 7.3.7.1-35 

S-CSCF forwards the ACK request to the MGCF. 

Table 7.3.7.1-35: ACK (S-CSCF to MGCF) 

ACK sip:mgcf2. home2.net SIP/2.0 
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Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



7.4 Termination procedures 



7.4.1 Introduction 

This subclause presents the detailed signalling flows to define the procedures for session terminations. 

The session termination procedures specify the signalling path between the S-CSCF assigned to perform the session 
termination service and the UE. This signalling path is determined at the time of UE registration, and remains fixed for 
the life of the registration. This signalling path is the reverse of the session initiation signalling path of subclause 7.2. 
Therefore there is a one-to-one correspondence between the origination procedures of subclause 7.2 and the termination 
procedures of this subclause. 

A UE always has a proxy (P-CSCF) associated with it. This P-CSCF is located in the same network as the UE, and 
performs resource authorization for the sessions to the UE. The P-CSCF is determined by the CSCF discovery process, 
described in subclause 5.2.1. 

As a result of the registration procedure, the P-CSCF knows the address of the UE. The assigned S-CSCF, in the home 
network, knows the name/address of the P-CSCF. If the network operator owning the S-CSCF wants to keep their 
configuration private, the S-CSCF will have chosen an Interrogating-CSCF, I-CSCF, who will perform the THIG 
functions and pass messages to the P-CSCF (procedure MT#lb). 

Sessions destined to the PSTN are a special case of the Termination procedures. Two of the S-CSCF to S-CSCF 
procedures deal specifically with PSTN termination, and route the session signalling through a BGCF that allocates a 
MGCF. The MGCF uses H.248/MEGACO to control a Media Gateway, and communicates with SS7 network. In case 
of interworking between IP based and SS7 based signalling network is required, a SGW would be used [2]. The MGCF 
receives and processes SIP requests, and subsequent nodes consider the signalling as if it came from a S-CSCF. 

7.4.2 l\/IT#1a 

7.4.2.1 (MT#1 a) Mobile termination, roaming (M0#1 a, S-S#1 a assumed) 

Figure 7.4.2.1 shows a termination procedure which applies to roaming subscribers when the home network operator 
does not desire to keep its internal configuration hidden from the visited network. The UE is located in a visited 
network, and determines the P-CSCF via the P-CSCF discovery procedure. During registration, the home network 
allocates the S-CSCF. 

When registration is complete, S-CSCF knows the name/address of P-CSCF and the UE Contact address, and P-CSCF 
obtains the name/address of the UE. 
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Figure 7.4.2.1-1 :MT#1 a 

Procedure MT#la is as follows: 

1 . INVITE (S-S to MT#la) - see example in table 7.4.2.1-1 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 
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Table 7.4.2.1-1 : INVITE (S-S to MT#1a) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip: scscf 2 .home2 . net; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 

P-Asserted-Identity : "John Doe" <sip : userl_publicl@homel . net>, <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: 

Contact: <sip: [5555: : aaa: bbb: ccc : ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

SDP The SDP contains the complete set of supported codecs from the session originator, as restricted 

by the originating network operator. The "m=" lines for the video media streams show a port 
number zero, which removes them from the negotiation. 

Upon receipt of the INVITE, the S-CSCF stores the following information about this session, for use in 
providing enhanced services, charging or in possible error recovery actions - see example in table 7.4.2. 1-lb. 

Table 7.4.2.1 -lb: Storage of information at S-CSCF 

I Request-URI : sip:user2_publicl@home2 . net 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest): 127 INVITE 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 223 ETSI TS 124 228 V5.3.0 (2002-12) 

CSeq(2orig) : none 

Route (2orig) : <sip:scscfl. homel . net; lr>, <sip:pcscfl. visitedl . net; lr> 

P-Charging-Vector : icid-value=1234bcd987 6e; ic id-gene rat ed-at= [5555::f5f:e4e:d3d:c2c]; orig- 

ioi=homel . net 
Contact (orig) : <sip: [5555: : aaa : bbb : ccc : ddd] > 

2. 100 Trying (MT#la to S-S) - see example in table 7.4.2.1-2 

S-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.4.2.1-2: 100 Trying (MT#1a to S-S) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscfl .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

4. INVITE (S-CSCF to P-CSCF) - see example in table 83.2-4 

S-CSCF remembers (from the registration procedure) the UE Contact address and the next hop CSCF for this 
UE. It forwards the INVITE to the P-CSCF. 

S-CSCF examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 

Table 7.4.2.1-4: INVITE (S-CSCF to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1, S IP /2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b2 3 . 1, 
SIP/ 2 .0/UDP pcscfl .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : <sip:pcscf2.visited2.net;lr> 

Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 

P-Called-Party-ID : <sip:user2_publicl@home2 . net> 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 
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b=AS:54.6 
a=curr : qo 
a=curr : qo 
a=des : qos 
a=des : qos 
a=rtpmap : 
m=audio 3 
b=AS:25.4 
a=curr : qo 
a=curr : qo 
a=des : qos 
a=des : qos 
a=rtpmap : 
a=fmtp:97 
a=rtpmap: 
m=audio 
b=AS:25.4 
a=curr : qo 
a=curr : qo 
a=des : qos 
a=des : qos 
a=rtpmap : 
a=fmtp:97 
a=rtpmap : 



local none 
remote none 
mandatory local sendrecv 
none remote sendrecv 
99:MPV 
456 RTP/AVP 97 96 15 

s local none 
remote none 

mandatory local sendrecv 

none remote sendrecv 
97 AMR 

mode-set=0, 2, 5, 7; maxframes=2 

96 G726-32/8000 
RTP/AVP 97 96 15 

local none 

remote none 
mandatory local sendrecv 
none remote sendrecv 

97 AMR 

mode-set=0, 2, 5, 7; maxframes=2 
96 G726-32/8000 



Route: Built from the Path header stored at registration. 

P-Called-Party-ID: Includes the dialled URL with its parameters. 
Via:/Record-Route: S-CSCF adds itself. 



SDP 



The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 
lines for the second audio stream shows a port number zero, which removes it from the 
negotiation. 



P-CSCF saves information from the received INVITE request. The saved value of the information for this 
session is - see example in table 7.4.2.1 -4b. 

Table 7.4.2.1 -4b: Storage of information at P-CSCF 

Request-URI : sip: +1-2 12-555-2222 @home2 .net;user=phone 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route(2orig) : <sip : scscf 2 . home2 . net ; lr>, <sip : scscf 1 . homel . net ; lr>, 

<sip:pcscfl .visitedl . net; lr> 
P-Charging-Vector : icld-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Contact (orlg) : <sip: [5555: : aaa : bbb : ccc : ddd] > 



5. 100 Trying (P-CSCF to S-CSCF) - see example in table 7.4.2.1-5 

P-CSCF responds to the INVITE request (4) with a 100 Trying provisional response. 

Table 7.4.2.1-5: 100 Trying (P-CSCF to S-CSCF) 



100 Trying 
P/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87. 1, SIP/2. 0/UDP 

s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
/UDP pcscfl. visitedl. net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 



SIP/2.0 
Via: SI 
icscf 2_ 
SIP/2. 
[5555 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



6. INVITE (P-CSCF to UE) - see example in table 7.4.2.1-6 
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P-CSCF examines the media parameters, and removes any that the network operator decides, based on local 
policy, not to allow on the network. 

For this example, assume the network operator does not allow 64 kb/s audio, so the PCMU codec is removed. 

P-CSCF removes the Record-Route and Via headers, calculates the proper Route header to add to future 
requests, and saves that information without passing it to UE. 

Table 7.4.2.1-6: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net; branch=z9hG4bK361k21 . 1 

Max-Forwards : 65 

P -Asserted- Identity : 

Privacy : 

P-Media-Authorization: 02 000 100 100 10 170 64 663 12e68 6f6d65312e6e6574 00c020 1333 1533 1343 63231 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

P-Called-Party-ID : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saves 

values. It inserts this as a branch value on its Via header. 

P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdfl.homel.net" with credentials "31S1462r'. 
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SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 

lines for the first audio stream no longer contains codec "0" (PCMU), which removes it 
from the negotiation. 

7. 100 Trying (UE to P-CSCF) - see example in table 7.4.2.1-7 

UE may optionally send a 100 Trying provisional response to P-CSCF. 

Table 7.4.2.1-7: 100 Trying (UE to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. 183 Session Progress (UE to P-CSCF) - see example in table 7.4.2.1-8 

UE#2 determines the complete set of codecs that it is capable of supporting for this session. It determines the 
intersection with those appearing in the SDP in the INVITE request. For each media flow that is not 
supported, UE#2 inserts a SDP entry for media (m= line) with port=0. For each media flow that is supported, 
UE#2 inserts a SDP entry with an assigned port and with the codecs in common with those in the SDP from 

UE#1. 

For this example, assume UE#2 supports both AMR and G726, but not G728 (code 15). 

UE responds with a 183 Session Progress response containing SDP back to the originator. This SDP may 
represent one or more media for a multimedia session. This response is sent to P-CSCF. 

Table 7.4.2.1-8: 183 Session Progress (UE to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: <tel:+l-212-555-2222>; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 
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To: A tag is added to the To header. 

Contact: Contains a SIP URL with the IP address or FQDN of the UE. 

SDP The SDP contains the subset of codecs supported by UE. It requests a confirmation of the 

QoS preconditions for establishing the session 

Upon receipt of the 183 Session Progress, the P-CSCF stores the following information about this session, for 
use in providing enhanced services or in possible error recovery actions - see example in table 7.4.2.1 -8b. 

Table 7.4.2.1 -8b: Storage of information at P-CSCF 



Request-URI: sip: [5555: : eee : f f f : aaa:bbb] 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest) : 127 INVITE 

CSeq(2orig) : none 

Route(2orig) : <sip: scscf 2 .home2 . net; lr>, <sip: scscf 1 .homel . net; lr>, 

<sip:pcscfl .visitedl . net; lr> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Contact (dest) : <sip: [5555: :eee:fff:aaa: bbb] > 
Contact (orig) : <sip: [5555: : aaa : bbb : ccc : ddd] > 

9. Authorize QoS Resources 

P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens 
at this stage or after 200 OK of INVITE (34) based on operator local policy. 

10. 183 Session Progress (P-CSCF to S-CSCF) - see example in table 7.4.2.1-10 

P-CSCF forwards the 183 Session Progress response to S-CSCF. 

Table 7.4.2.1-10: 183 Session Progress (P-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7) 

Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel . net ; lr>, 
<sip: pcscfl .visitedl . net; lr> 

P-Asserted-Identity : "John Smith" <sip:user2_publicl@home2 . net> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c= 

t = 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 228 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Via:/Record-Route: P-CSCF restores the Via headers and Record-Route headers from the branch value in its Via. 

P-Asserted-Identity: P-CSCF inserts the default SIP URI of the user in the P-Asserted-Identity header field. 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Upon receipt of the 183 Session Progress, the S-CSCF stores the following information about this session, for 
use in providing enhanced services or in possible error recovery actions - see example in table 7.4.2. 1-lOb. 

Table 7.4.2. 1-10b: Storage of information at S-CSCF 

Re quest -URI ; sip ; user2_publicl@home2 .net 
From; <sip ; userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest): 127 INVITE 
CSeq(2orig) : none 

Route (2dest ) : <sip:pcscf 2 . visited2 . net; lr> 

Route(2orig) : <sip : scscf 1 . homel . net ; lr>, <sip:pcscf 1 . visitedl . net; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Contact (dest) : <sip: [5555: :eee:fff: aaa:bbb] > 
I Contact (orig) : <sip: [5555 : : aaa:bbb: ccc: ddd] > 

1 1. 183 Session Progress (MT#la to S-S) - see example in table 7.4.2.1-11 

S-CSCF forwards the 183 Session Progress response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.4.2.1-11 : 183 Session Progress (MT#1a to S-S) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net>, <tel : +l-212-555-2222> 

P-Charging-Vector : icid-value = 1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

P-Charging-Funct ion-Addresses: ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555::a5 5:b4 4:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 
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P-Asserted-Identity: S-CSCF inserts the TEL URI of the user in the P-Asserted-Identity header field. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header and puts back the originating lOI parameter. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 

12. PRACK (S-S to MT#la) - see example in table 7.4.2.1-12 

The originating endpoint sends a PRACK request containing the final SDP to be used in this session, via the 
S-CSCF to S-CSCF procedure, to S-CSCF. 

Table 7.4.2.1-12: PRACK (S-S to MT#1a) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>; tag=314159 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 128 PRACK 
Require: precondition 
Rack: 9021 127 INVITE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

13. PRACK (S-CSCF to P-CSCF) - see example in table 7.4.2.1-13 

S-CSCF forwards the PRACK request to P-CSCF. 

Table 7.4.2.1-13: PRACK (S-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 
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14. PRACK (P-CSCF to UE) - see example in table 7.4.2.1-14 

P-CSCF forwards the PRACK request to UE. 

Table 7.4.2.1-14: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 
values. It inserts this as a branch value on its Via header. 



15. 200 OK (UE to P-CSCF) - see example in table 7.4.2.1-15 

UE acknowledges the PRACK request (14) with a 200 OK response. 

Table 7.4.2.1-15: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 
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a=curr:qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 
24.229 [16]. 

16. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.2.1-16 

P-CSCF forwards the 200 OK response to S-CSCF. 



Table 7.4.2.1-16: 200 OK (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

17. 200 OK (MT#la to S-S) - see example in table 7.4.2.1-17 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.4.2.1-17: 200 OK (MT#1a to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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18. Resource Reservation 

UE initiates the reservation procedures for the resources needed for this session. 

19. UPDATE (S-S to MT#la) - see example in table 7.4.2.1-19 

When the originating endpoint has completed its resource reservation, it sends the UPDATE request to S- 
CSCF, via the S-CSCF to S-CSCF procedures. 

Table 7.4.2.1-19: UPDATE (S-S to MT#1a) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK24 0f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 129 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

20. UPDATE (S-CSCF to P-CSCF) - see example in table 7.4.2.1-20 

S-CSCF forwards the UPDATE request to P-CSCF. 

Table 7.4.2.1-20: UPDATE (S-CSCF to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 
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Content-Type : 
Content-Length : 



21. UPDATE (P-CSCF to UE) - see example in table 7.4.2.1-21 

P-CSCF forwards the UPDATE request to UE. 

Table 7.4.2.1-21 : UPDATE (P-CSCF to UE) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 
values. It inserts this as a branch value on its Via header. 



22. 200 OK (UE to P-CSCF) - see example in table 7.4.2.1-22 

UE acknowledges the UPDATE request (21) with a 200 OK response. 

Table 7.4.2.1-22: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 
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o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 
24.229 [16]. 

23. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.2.1-23 

P-CSCF forwards the 200 OK response to S-CSCF. 



Table 7.4.2.1-23: 200 OK (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

24. 200 OK (MT#la to S-S) - see example in table 7.4.2.1-24 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.4.2.1-24: 200 OK (MT#1a to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
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Content-Type : 
Content-Length : 



25. 180 Ringing (UE to P-CSCF) - see example in table 7.4.2.1-25 

Before proceeding with session establishment, the UE waits for two events. First, the resource reservation 
initiated in step #17 must complete successfully. Second, the resource reservation initiated by the originating 
endpoint must complete successfully (which is indicated by message #20 received by UE). The UE may now 
immediately accept the session (and proceed with step #34), or alert the destination subscriber of an 
incoming session attempt; if the latter it indicates this to the calling party by a 180 Ringing provisional 
response sent to P-CSCF. 

Table 7.4.2.1-25: 180 Ringing (UE to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9022 

Content-Length: 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 
24.229 [16]. 

26. 180 Ringing (P-CSCF to S-CSCF) - see example in table 7.4.2.1-26 

P-CSCF forwards the 180 Ringing response to S-CSCF. 

Table 7.4.2.1-26: 180 Ringing (P-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscf l.visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : <sip:pcscf2 .visited2 . net; lr>, <sip: scscf2 . home 2 .net;lr>, <sip:scscfl. homel .net; lr>, 
<sip:pcscfl .visitedl . net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 
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P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Upon receipt of the 180, the S-CSCF stores the following information about this session, for use in charging 
- see example in table 7.4.2. l-26b. 

Table 7.4.2. 1-26b: Storage of information at S-CSCF 

I Request-URI ; sip;user2_publicl@home2 . net 
From: <sip ; userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest) : 127 INVITE 
CSeq(2orig) : none 

Route (2clest ) : <sip:pcscf 2 . visitecl2 . net; lr> 

Route(2orig) : <sip: scscf 1 .homel . net; lr>, <sip:pcscf 1 . visitedl . net; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel . net ; term-ioi=home2 . net; ggsn= [5555 : : d6d: c7c :b8b: a9a] ; pdp-sig=no; 
gcid=309685742; auth-token=86243614; flow-id=3 
Contact (dest) : <sip: [5555: :eee:fff:aaa: bbb] > 
Contact (orig) : <sip: [5555: : aaa : bbb : ccc : ddd] > 



27. 180 Ringing (MT#la to S-S) - see example in table 7.4.2.1-27 

S-CSCF forwards the 180 Ringing response to the originating endpoint, per the S-CSCF to S-CSCF 
procedure. 

Table 7.4.2.1-27: 180 Ringing (MT#1a to S-S) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscfl .visited. net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

28. PRACK (S-S to MT#la) - see example in table 7.4.2.1-28 

The originator acknowledges the 180 Ringing response (27) with a PRACK request. 

Table 7.4.2.1-28: PRACK (S-S to MT#1a) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl. visitedl. net ;branch=z9hG4bK24 Of 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 

29. PRACK (S-CSCF to P-CSCF) - see example in table 7.4.2.1-29 

S-CSCF forwards the PRACK request to P-CSCF. 
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Table 7.4.2.1-29: PRACK (S-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

30. PRACK (P-CSCF to UE) - see example in table 7.4.2.1-30 
P-CSCF forwards the PRACK request to UE. 

Table 7.4.2.1-30: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

31. 200 OK (UE to P-CSCF) - see example in table 7.4.2.1-31 

UE acknowledges the PRACK request (31) with a 200 OK response. 

Table 7.4.2.1-31 : 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

32. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.2.1-32 

P-CSCF forwards the 200 OK response to S-CSCF. 

Table 7.4.2.1-32: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 

ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

Upon receipt of the 200, the S-CSCF stores the following information about this session (unless already done 
if information received with the 180), for use in charging - see example in table 7.4.2. l-32b. 
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Table 7.4.2. 1-32b: Storage of information at S-CSCF 



Request-URI : sip : user2_publicl@home2 . net 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route (2clest ) : <sip:pcscf 2 . visitecl2 . net; lr> 

Route(2orig) : <sip : scscf 1 . homel . net ; lr>, <sip:pcscf 1 . visitedl . net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net ; term-ioi=home2 . net; ggsn= [5555 : : d6d: c7c :b8b: a9a] ; pdp-sig=no; 

gcid=309685742; auth-token=86243614; flow-id=3 
Contact (dest) : <sip: [5555: :eee:fff: aaa:bbb] > 
Contact (orig) : <sip: [5555: : aaa:bbb: ccc : ddd] > 

33. 200 OK (MT#la to S-S) - see example in table 7.4.2.1-33 

S-CSCF forwards the 200 OK response to the session originator, per the S-CSCF to S-CSCF procedures. 

Table 7.4.2.1-33: 200 OK (MT#1a to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

34. 200 OK (UE to P-CSCF) - see example in table 7.4.2.1-34 

When the called party answers the UE sends a 200 OK final response to the INVITE request (6) to P-CSCF, 
and starts the media flow(s) for this session. 

Table 7.4.2.1-34: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

Content-Length: 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP TS 

24.229 [16]. 

35. Approval of QoS Commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (9). 
36. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.2.1-36 
P-CSCF sends the 200 OK final response to S-CSCF. 

Table 7.4.2.1-36: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 

SIP/2. 0/UDP pcscfl. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Record-Route : <sip:pcscf 2 . visited2 . net; lr>, <sip:scscf2 .home 2 . net; lr>, <sip:scscfl .homel . net; lr>, 

<sip:pcscf 1 . visitedl . net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From; 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

37. 200 OK (MT#la to S-S) - see example in table 7.4.2.1-37 

S-CSCF forwards the 200 OK final response along the signalling path back to the session originator, as per 
the S-CSCF to S-CSCF procedure. 

Table 7.4.2.1-37: 200 OK (MT#1a to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP Icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscfl .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

38. ACK (S-S to MT#la) - see example in table 7.4.2.1-38 

The calling party responds to the 200 OK final response (37) with an ACK request which is sent to S-CSCF 
via the S-CSCF to S-CSCF procedure. 



Table 7.4.2.1-38: ACK (S-S to MT#1a) 



ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 127 ACK 
Content-Length: 

39. ACK (S-CSCF to P-CSCF) - see example in table 7.4.2.1-39 

S-CSCF forwards the ACK request to P-CSCF. 

Table 7.4.2.1-39: ACK (S-CSCF to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscfl . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 
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40. ACK (P-CSCF to UE) - see example in table 7,4,2,1-40 
P-CSCF forwards the ACK request to UE. 

Table 7.4.2.1-40: ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

7.4.2.2 UE-detected failure/resource failure 

The subscriber that initiated a session with one of the MO procedures had the attempt fail due to an error detected in the 
Termination procedure. This could be due to, for example, destination busy (error code 486), or some other error. 

Depending on the exact error that causes the session initiation failure, and when the error situation was detected, MT#la 
could be at many different stages in the session establishment procedure. This is shown in figure 7.4.2.2-1, as optional 
messages 7-33 that may appear in this error procedure. 

This subclause also includes the procedures for the terminating UE to indicate a failure to allocate required resources 
for the session. This is detected in step #18 and reported with a 580-Precondition-Failure error response. 
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Figure 7.4.2.2-1 : Failure in termination procedure 
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UE#1 initiated a session, as described in subclause 7.4.2.1. 

7-33.100 Trying (S-CSCF to S-S) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.4.2.1. 

34. XXX Error (UE to P-CSCF) - see example in table 7.4.2.2-34 

The termination procedure detected some error situation, and returned a SIP error response. 

NOTE 1: The error response may be, for example, "486 Busy", "403 Service Denied", "480 Temporarily 
Unavailable", "580 Precondition Failure", or others. For this example, "486 Busy" is shown. 

Table 7.4.2.2-34: 486 Busy Here (UE to P-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

From; <sip ; userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Retry-After: 3600 

Content-Length: 

35. ACK (P-CSCF to UE) - see example in table 7.4.2.2-35 

Upon receive the 486 response from the UE, P-CSCF sends ACK. 

Table 7.4.2.2-35: ACK (P-CSCF to UE) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 . net;branch=z9hG4bK764z87 . 1 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

36. Revoke QoS authorization 

P-CSCF removes the QoS authorization, if any, for this session. 

37. XXX Error (P-CSCF to S-CSCF) - see example in table 7.4.2.2-37 (related to table 7.4.2.2-34) 

The P-CSCF returned a SIP error response to S-CSCF. 

NOTE 2: The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 

Table 7.4.2.2-37: 486 Busy Here (P-CSCF to S-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .home 1 . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 ) 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

38. ACK (S-CSCF to P-CSCF) - see example in table 7.4.2.2-38 

Upon receive the 486 response from the P-CSCF procedure, S-CSCF sends ACK. 
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Table 7.4.2.2-38: ACK (S-CSCF to P-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 . net; branch=z9hG4bK764z87 . 1 

Route ; <sip;pcscf2.visitecl2.net;lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

39. XXX Error (S-CSCF to S-S) - see example in table 7.4.2.2-39 (related to table 7,4,2,2-37) 

The S-CSCF returned a SIP error response to the appropriate S-S procedure. 

NOTE 3: The error response may be, for example, "486 (Busy Here)", "403 (Forbidden)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 

Table 7.4.2.2-39: 486 Busy Here (S-CSCF to S-S) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

40. ACK (S-S to S-CSCF) - see example in table 7,4,2,2-40 

Upon receive the 486 response from the S-CSCF, the S-S procedure sends ACK. 

Table 7.4.2.2-40: ACK (S-S to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Route: <sip: scscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



7.4.2.3 Origination failure 

After sending the initial INVITE for a multimedia session, the originating endpoint either abandoned the attempt or was 
unable to obtain the resources necessary for the session. The termination procedure is informed of this by a CANCEL 
request from the originator, which is shown in figure 7.4.2.3-1. 

If the session is aborted due to failure to obtain resources by the originator, it will occur prior to step #19; steps 19-33 
(marked as optional) will not be present. If the session is abandoned due to user command, it can happen at any point 
between steps 8-33. 
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Figure 7.4.2.3-1: Failure in origination procedure 
1-7. INVITE (S-S to S-CSCF) et seq 
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UE#1 initiated a session, as described in subclause 7.4.2.1. 

8-33.183 Session Progress (UE to S-CSCF) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 7.4.2.1. 

34. CANCEL (S-S to S-CSCF) - see example in table 7.4.2.3-34 

The originator, through the S-S procedure, cancelled the original INVITE request. 

Table 7.4.2.3-34: CANCEL (S-S to S-CSCF) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

Route: <sip: scscf 2 .home2 . net; lr> 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 CANCEL 

Content-Length: 

35. 200 OK (S-CSCF to S-S) - see example in table 7.4.2.3-35 

Upon receive the CANCEL request from the S-S procedure, S-CSCF sends 200 OK. 

Table 7.4.2.3-35: 200 OK (S-CSCF to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

36. CANCEL (S-CSCF to P-CSCF) - see example in table 7.4.2.3-36 

The S-CSCF forwards the CANCEL request to P-CSCF. 

Table 7.4.2.3-36: CANCEL (S-CSCF to P-CSCF) (related to 7.4.2.3-34) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

37. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.2.3-37 

Upon receiving the CANCEL request from the S-CSCF, P-CSCF sends 200 OK. 

Table 7.4.2.3-37: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

38. Revoke QoS authorization 
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P-CSCF removes the QoS authorization, if any, for this session. 
39. CANCEL (P-CSCF to UE) - see example in table 7.4.2.3-39 (related to table 7.4.2,3-36) 

The P-CSCF forwards the CANCEL request to the UE. 

Table 7.4.2.3-39: CANCEL (P-CSCF to UE) 

CANCEL sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

40. 200 OK (UE to P-CSCF) - see example in table 7.4.2.3-40 

Upon receive the CANCEL request from the P-CSCF, the UE sends 200 OK. 

Table 7.4.2.3-40: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

4L 487 Request Terminated (UE to P-CSCF) - see example in table 7.4.2.3-41 

The termination procedure performed the cancel operation, and returned a SIP error response to the initial 
INVITE request. 

Table 7.4.2.3-41 : 487 Request Terminated (UE to P-CSCF) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Retry-After: 3600 

Content-Length: 

42. ACK (P-CSCF to UE) - see example in table 7.4.2.3-42 

Upon receive the 487 response from the UE, P-CSCF sends ACK. 

Table 7.4.2.3-42: ACK (P-CSCF to UE) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

43. 487 Request Terminated (P-CSCF to S-CSCF) - see example in table 7.4.2.3-43 (related to table 7.4.2.3-41) 

The P-CSCF returns the SIP error response to S-CSCF. 

Table 7.4.2.3-43: 487 Request Terminated (P-CSCF to S-CSCF) 

SIP/2.0 487 Request Terminated 
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Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7) 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

44. ACK (S-CSCF to P-CSCF) - see example in table 7.4.2.3-44 

Upon receive the 487 response from the P-CSCF procedure, S-CSCF sends ACK. 

Table 7.4.2.3-44: ACK (S-CSCF to P-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

45. 487 Request Terminated (S-CSCF to S-S) - see example in table 7.4.2.3-45 (related to table 7.4.2.3-43) 
The S-CSCF returns the SIP error response to the appropriate S-S procedure. 

Table 7.4.2.3-45: 487 Request Terminated (S-CSCF to S-S) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

46. ACK (S-S to S-CSCF) - see example in table 7.4.2.3-46 

Upon receive the 487 response from the S-CSCF, the S-S procedure sends ACK. 

Table 7.4.2.3-46: ACK (S-S to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net;user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Route: <sip: scscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



7.4.2.4 Mobile termination, roaming, terminal is out of radio coverage (M0#2, S-S#2 
assumed) 

An example of this flow is not shown in the present document. 

7.4.3 MT#2 

7.4.3.1 (MT#2) Mobile termination, located in home network (M0#2, S-S#2 

assumed) 
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Figure 7.4.3. 1-1 shows a termination procedure which applies to subscribers located in their home service area. 

The UE is located in the home network, and determines the P-CSCF via the CSCF discovery procedure. During 
registration, the home network allocates a S-CSCF in the home network, S-CSCF. 

When registration is complete, S-CSCF knows the name/address of P-CSCF, and P-CSCF knows the name/address of 
the UE. 

NOTE: Although S-S#2 flow is assumed, home2.net is used in the Via, Record-Route and Route headers in order 
to be more generic and clearly identify the originating and terminating nodes. In the S-S#2 scenario 
home2.net = homel.net. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



249 



ETSI TS 124 228 V5.3.0 (2002-12) 



Home Network 



S-CSCF 



1. INVITE 
2. 100 Trying 



P-CSCF 



3. Evaluation of Initial 
Filter Criterias 



11. 183 

M Session 

Progress 



"PRACK" 



17. 200 OK- 
19. UPDATE 



< — 24. 200 OK 

<27. 180 Ringing 
28. PRACK 



33. 200 OK 



37. 200 OK 

38. ACK ► 



4. INVITE 



5. 100 Trying 



UE#2 



6. INVITE 

7. 100 Trying 

8. 183 

— Session — 

— Progress 



9. Authorize OoS Resources 

lU. 183 

Session 

Progress 



13. 
PRACK" 



16. 200OK- 



20. UPDATE 



23. 200 OK- 



26. 180 
Ringing 



29. PRACK 



32. 200 OK 



_ 14. 

PRACK 

15. 200 OK 



18. Resource 
Reservation 



21. UPDATE H 

22. 200 OK 



25. 180 
Ringing 



30. PRACK 



31. 200 OK 
34. 200 OK 



35. Approval of OoS Commit 



36. 200 OK- 



39. ACK- 



40. ACK 



Figure 7.4.3.1-1: MT#2 
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Procedure MT#2 is as follows: 

1 . INVITE (S-S to MT#2) - see example in table 7.4.3.1-1 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 

Table 7.4.3.1-1 : INVITE (S-S to MT#2) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip: scscf 2 .homel . net; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Contact: <sip: [5555: : aaa: bbb: ccc : ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

SDP The SDP contains the complete set of supported codecs from the session originator, as restricted 

by the originating network operator. The "m=" lines for the video media streams show a port 
number zero, which removes them from the negotiation. 

Upon receipt of the INVITE, the S-CSCF stores the following information about this session, for use in 
providing enhanced services, charging or in possible error recovery actions - see example in table 7.4.3. 1-lb. 
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Table 7.4.3.1 -1b: Storage of information at S-CSCF 



Request-URI: sip: user2_publicl@home2.net 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route(2orig) : <sip: scscf 1 .homel . net; lr>, <sip:pcscf 1 .homel . net; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

Contact (orig) : <sip: [5555: : aaa : bbb : ccc : ddd] > 



2. 100 Trying (MT#2 to S-S) - see example in table 7.4.3.1-2 

S-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.4.3.1-2: 100 Trying (l\flT#2 to S-S) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

4. INVITE (S-CSCF to P-CSCF) - see example in table 7.4.3.1-4 

S-CSCF remembers (from the registration procedure) the next hop CSCF for this UE. It forwards the 
INVITE request to the P-CSCF. 

S-CSCF examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 

Table 7.4.3.1-4: INVITE (S-CSCF to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1 SIP/ 2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b2 3 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route: <sip:pcscf 2 .home2 . net; lr> 

Record-Route: <sip: scscf 2 .home2 . net; lr>, <sip: scscf 1 .homel . net; lr>, <sip:pcscfl .homel . net; lr> 
P -As sorted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 

P-Called-Party-ID: <tel:+l-212-555-2222> 
Content-Type : 
Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 
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m=video RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Route: 

P-Called-Party-ID: 
Via:, Record-Route: 
SDP: 



Built from the Path header stored at registration. 

Includes the dialled URL with its parameters. 

S-CSCF adds itself in the Record-Route and Via headers. 

The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 
lines for the second audio stream shows a port number zero, which removes it from the 
negotiation. 



P-CSCF saves information from the received INVITE request. The saved value of the information for this 
session is - see example in table 7.4.3. l-4b. 

Table 7.4.3.1 -4b: Storage of information at P-CSCF 

Request-URI: sip: [5555: : eee : f f f : aaa:bbb] 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest): 127 INVITE 
CSeq(2orig) : none 

Route(2orig) : <sip : scscf 2 . home2 . net ; lr>, <sip : scscf 1 . homel . net ; lr>, 
<sip:pcscfl . homel .net; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
I Contact (orig) : <sip : [5555 : : aaa : bbb : ccc : ddd] > 



5. 100 Trying (P-CSCF to S-CSCF) - see example in table 7.4.3.1-5 

P-CSCF responds to the INVITE request (4) with a 100 Trying provisional response. 



Table 7.4.3.1-5: 100 Trying (P-CSCF to S-CSCF) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
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Call-ID: 
CSeq: 
Content-Length : 



6. INVITE (P-CSCF to UE) - see example in table 7.4.3.1-6 

P-CSCF examines the media parameters, and removes any that the network operator decides, based on local 
policy, not to allow on the network. 

For this example, assume the network operator does not allow 64 kb/s audio, so the PCMU codec is removed. 

P-CSCF removes the Record-Route and Via headers, calculates the proper Route header to add to future 
requests, and saves that information without passing it to UE. 

Table 7.4.3.1-6: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 .home2 . net; branch=z9hG4bK876tl2 . 1 

Max-Forwards : 65 

P -Asserted- Identity : 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

P-Called-Party-ID : 

P-Media-Authorization: 0020000 100 100 10 170 64 66322e68 6f6d65312e6e6574 00c020 1333 1533 1343 63231 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saves 
values. It inserts this as a branch value on its Via header. 
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P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdfl.homel.net" with credentials "31814621". 

SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 

lines for the first audio stream no longer contains codec "0" (PCMU), which removes it 
from the negotiation. 

7. 100 Trying (UE to P-CSCF) - see example in table 7.4.3.1-7 

UE may optionally send a 100 Trying provisional response to P-CSCF. 

Table 7.4.3.1-7: 100 Trying (UE to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. 183 Session Progress (UE to P-CSCF) - see example in table 7.4.3.1-8 

UE#2 determines the complete set of codecs that it is capable of supporting for this session. It determines the 
intersection with those appearing in the SDP in the INVITE request. For each media flow that is not 
supported, UE#2 inserts a SDP entry for media (m= line) with port=0. For each media flow that is supported, 
UE#2 inserts a SDP entry with an assigned port and with the codecs in common with those in the SDP from 

UE#1. 

For this example, assume UE#2 supports both AMR and G726, but not G728 (code 15). 

UE responds with a 183 Session Progress response containing SDP back to the originator. This SDP may 
represent one or more media for a multimedia session. This response is sent to P-CSCF. 

Table 7.4.3.1-8: 183 Session Progress (UE to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ;branch=z9hG4bK876t 12 . 1 

Privacy: none 

From: 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

To: A tag is added to the To header. 
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Contact: Contains a SIP URL with the IP address or FQDN of the terminating UE. 

SDP The SDP contains the subset of codecs supported by UE. It requests a confirmation of the 

QoS preconditions for establishing the session. 

Upon receipt of the 183 Session Progress, the P-CSCF stores the following information about this session, 
for use in providing enhanced services or in possible error recovery actions - see example in table 7.4.3. l-8b. 

Table 7.4.3.1 -8b: Storage of information at P-CSCF 

[ Request-URI: sip: [5555 :: eee : fff: aaa:bbb] 
From: <sip : userl_publicl@homel .net>;tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest) : 127 INVITE 
CSeq(2orig) : none 

Route(2orig) : <sip: scscf 2 .home2 . net; lr>, <sip: scscf 1 .homel . net; lr>, 
<sip:pcscfl . homel .net; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Contact (dest) : <sip: [5555: :eee:fff: aaa:bbb] > 
Contact (orig) : <sip: [5555: : aaa : bbb : ccc : ddd] > 



9. Authorize QoS Resources 

P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens 
at this stage or after 200 OK of INVITE (34) based on operator local policy. 

10. 183 Session Progress (P-CSCF to S-CSCF) - see example in table 7.4.3.1-10 

P-CSCF forwards the 183 Session Progress response to S-CSCF. 

Table 7.4.3.1-10: 183 Session Progress (P-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 ) 

Record-Route: <sip:pcscf 2 .home2 . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip: scscf 1 .homel . net; lr>, 
<sip:pcscfl . homel .net; lr> 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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P-CSCF restores the Via headers and Record-Route headers from the branch value in its Via. 

P-Asserted-Identity: P-CSCF inserts the defauh SIP URI of the user in the P-Asserted-Identity header field. 

Upon receipt of the 183 Session Progress, the S-CSCF stores the following information about this session, 
for use in providing enhanced services or in possible error recovery actions - see example in table 7.4.3.1- 
10b. 

Table 7.4.3.1-10b: Storage of information at S-CSCF 

I Request-URI ; sip;user2_publicl@home2 . net 
From: <sip ; userl_publicl@homel .net>;tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest) : 127 INVITE 
CSeq(2orig) : none 

Route (2clest ) : <sip:pcscf 2 .home2 . net; lr> 

Route(2orig) : <sip: scscf 1 .homel . net; lr>, <sip:pcscf 1 .homel . net; lr> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Contact (dest) : <sip: [5555: :eee:fff: aaa:bbb] > 
Contact (orig) : <sip: [5555: : aaa:bbb: ccc : ddd] > 



11. 183 Session Progress (MT#2 to S-S) - see example in table 7.4.3.1-11 

S-CSCF forwards the 183 Session Progress response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.4.3.1-11 : 183 Session Progress (MT#2 to S-S) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

P -As sorted- Identity: 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

P-Charging-Funct ion-Addresses: ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555::a55:b4 4:c33:d221; 

ecf=[5555::lff:2ee:3dd:4cc]; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



P-Charging- Vector: The S-CSCF adds the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header and puts back the originating lOI parameter. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 
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12. PRACK (S-S to MT#2) - see example in table 7.4.3.1-12 

The originating endpoint sends a PRACK request containing the final SDP to be used in this session, via the 
S-CSCF to S-CSCF procedure, to S-CSCF. 

Table 7.4.3.1-12: PRACK (S-S to MT#2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 128 PRACK 

Require: precondition 

Rack: 9021 127 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

13. PRACK (S-CSCF to P-CSCF) - see example in table 7.4.3.1-13 

S-CSCF forwards the PRACK request to P-CSCF. 

Table 7.4.3.1-13: PRACK (S-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip:pcscf2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 
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14. PRACK (P-CSCF to UE) - see example in table 7.4.3.1-14 
P-CSCF forwards the PRACK request to UE. 

Table 7.4.3.1-14: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

15. 200 OK (UE to P-CSCF) - see example in table 7.4.3.1-15 

UE acknowledges the PRACK request (14) with a 200 OK response. 

Table 7.4.3.1-15: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

1=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 
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16. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.3.1-16 
P-CSCF forwards the 200 OK response to S-CSCF. 

Table 7.4.3.1-16: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



17. 200 OK (MT#2 to S-S) - see example in table 7.4.3.1-17 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.4.3.1-17: 200 OK (MT#2 to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



18. Resource Reservation 

UE initiates the reservation procedures for the resources needed for this session. 
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19. UPDATE (S-S to MT#2) - see example in table 7.4.3.1-19 

When the originating endpoint has completed its resource reservation, it sends the UPDATE request to S- 
CSCF, via the S-CSCF to S-CSCF procedures. 

Table 7.4.3.1-19: UPDATE (S-S to MT#2) 

UPDATE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net ; lr> 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 129 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m-video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

20. UPDATE (S-CSCF to P-CSCF) - see example in table 7.4.3.1-20 

S-CSCF forwards the UPDATE request to P-CSCF. 

Table 7.4.3.1-20: UPDATE (S-CSCF to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip:pcscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c = 

t = 



21. UPDATE (P-CSCF to UE) - see example in table 7.4.3.1-21 
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P-CSCF forwards the UPDATE request to UE. 

Table 7.4.3.1-21 : UPDATE (P-CSCF to UE) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 

c = 

t = 



Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

22. 200 OK (UE to P-CSCF) - see example in table 7.4.3.1-22 

UE acknowledges the UPDATE request (21) with a 200 OK response. 

Table 7.4.3.1-22: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .home2 . net; branch=z9hG4bK876tl2 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



23. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.3.1-23 

P-CSCF forwards the 200 OK response to S-CSCF. 
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Table 7.4.3.1-23: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c = 

t = 



24. 200 OK (MT#2 to S-S) - see example in table 7.4.3.1-24 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.4.3.1-24: 200 OK (MT#2 to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 



25. 180 Ringing (UE to P-CSCF) - see example in table 7.4.3.1-25 

Before proceeding with session estabHshment, the UE waits for two events. First, the resource reservation 
initiated in step #17 must complete successfully. Second, the resource reservation initiated by the originating 
endpoint must complete successfully (which is indicated by message #20 received by UE). The UE may now 
immediately accept the session (and proceed with step #34), or alert the destination subscriber of an 
incoming session attempt; if the latter it indicates this to the calling party by a 180 Ringing provisional 
response sent to P-CSCF. 
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Table 7.4.3.1-25: 180 Ringing (UE to P-CSCF) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf2 .home2 . net;branch=z9hG4bK876tl2 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9022 

Content-Length: 



26. 180 Ringing (P-CSCF to S-CSCF) - see example in table 7.4.3.1-26 
P-CSCF forwards the 180 Ringing response to S-CSCF. 



Table 7.4.3.1-26: 180 Ringing (P-CSCF to S-CSCF) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP /2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: <sip:pcscf 2 .home2 . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip: scscf 1 .homel . net; lr>, 
<sip:pcscf 1 .homel . net; lr> 

P-Charging-Vector : icid-value=1234bcd987 6e; ic id-gene rat ed-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

Upon receipt of the 180, the S-CSCF stores the following information about this session, for use in charging 
- see example in table 7.4.2. l-26b. 

Table 7.4.2. 1-26b: Storage of information at S-CSCF 



Request-URI : sip : user2_publicl@home2 . net 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route(2dest) : <sip:pcscf 2 . visited2 . net; lr> 

Route(2orig) : <sip: scscf 1 .homel .net; lr>, <sip:pcscf 1 . visitedl . net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net ; term-ioi=home2 . net ; ggsn= [5555 : : d6d: c7c : b8b : a9a] ; pdp-sig=no; 

gcid=309685742; auth-token=86243614; flow-id=3 
Contact (dest) : <sip: [5555: :eee:fff: aaa: bbb] > 
Contact (orig) : <sip: [5555: : aaa : bbb : ccc : ddd] > 



27. 180 Ringing (MT#2 to S-S) - see example in table 7.4.3.1-27 

S-CSCF forwards the 180 Ringing response to the originating endpoint, per the S-CSCF to S-CSCF 
procedure. 

Table 7.4.3.1-27: 180 Ringing (MT#2 to S-S) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

From: 
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To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 



28. PRACK (S-S to MT#2) - see example in table 7.4.3.1-28 

The originator acknowledges the 180 Ringing response (27) with a PRACK request. 

Table 7.4.3.1-28: PRACK (S-S to MT#2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: scscf 2 . home2 . net ; lr>, <sip : pcscf 2 . home2 . net ; lr> 

From: 

To: 

Call-ID: 

Cseq: 130 PRACK 

Rack: 9022 127 INVITE 

Content-Length: 

29. PRACK (S-CSCF to P-CSCF) - see example in table 7.4.3.1-29 

S-CSCF forwards the PRACK request to P-CSCF. 

Table 7.4.3.1-29: PRACK (S-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip:pcscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

30. PRACK (P-CSCF to UE) - see example in table 7.4.3.1-30 

P-CSCF forwards the PRACK request to UE. 

Table 7.4.3.1-30: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 
values. It inserts this as a branch value on its Via header. 



31. 200 OK (UE to P-CSCF) - see example in table 7.4.3.1-31 

UE acknowledges the PRACK request (31) with a 200 OK response. 
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Table 7.4.3.1-31 : 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .home2 . net;branch=z9hG4bK876tl2 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

32. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.3.1-32 

P-CSCF forwards the 200 OK response to S-CSCF. 

Table 7.4.3.1-32: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 

ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

Upon receipt of the 200, the S-CSCF stores the following information about this session (unless already done 
if information received with the 180), for use in charging - see example in table 7.4.2. l-32b. 

Table 7.4.2. 1-32b: Storage of information at S-CSCF 

Request-URI : sip : user2_publicl@home2 . net 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route(2dest) : <sip:pcscf 2 . visited2 . net; lr> 

Route(2orig) : <sip: scscf 1 .homel . net; lr>, sip:pcscf 1 . visitedl . net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net ; term-ioi=home2 . net; ggsn= [5555 : : d6d: c7c :b8b: a9a] ; pdp-sig=no; 

gcid=309685742; auth-token=86243614; flow-id=3 
Contact (dest) : <sip: [5555: :eee:fff:aaa: bbb] > 
Contact (orig) : <sip: [5555: :aaa: bbb : ccc : ddd] > 

33. 200 OK (MT#2 to S-S) - see example in table 7.4.3.1-33 

S-CSCF forwards the 200 OK response to the session originator, per the S-CSCF to S-CSCF procedures. 

Table 7.4.3.1-33: 200 OK (MT#2 to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

34. 200 OK (UE to P-CSCF) - see example in table 7.4.3.1-34 

When the called party answers, the UE sends a 200 OK final response to the INVITE request (6) to P-CSCF, 
and starts the media flow(s) for this session. 
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Table 7.4.3.1-34: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .home2 . net;branch=z9hG4bK876tl2 . 1 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip: [5555: : eee : f f f : aaa :bbb] > 

Content-Length: 

35. Approval of QoS Commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (9). 

36. 200 OK (P-CSCF to S-CSCF) - see example in table 7.4.3.1-36 

P-CSCF indicates the resources reserved for this session should now be committed, and sends the 200 OK 
final response to S-CSCF. 

Table 7.4.3.1-36: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP icscf2.home2.net, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: <sip:pcscf 2 .home2 . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip: scscf 1 .homel . net; lr>, 

<sip:pcscfl . homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

37. 200 OK (MT#2 to S-S) - see example in table 7.4.3.1-37 

S-CSCF forwards the 200 OK final response along the signalling path back to the session originator, as per 
the S-CSCF to S-CSCF procedure. 

Table 7.4.3.1-37: 200 OK (MT#2 to S-S) 

SIP/2.0 200 OK 

Via: SIP/ 2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/ 2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

38. ACK (S-S to MT#2) - see example in table 7.4.3.1-38 

The calling party responds to the 200 OK final response (37) with an ACK request which is sent to S-CSCF 
via the S-CSCF to S-CSCF procedure. 



Table 7.4.3.1-38: ACK (S-S to MT#2) 



ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 127 ACK 
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Content-Length: 

39. ACK (S-CSCF to P-CSCF) - see example in table 7.4.3.1-39 

S-CSCF forwards the ACK request to P-CSCF. 

Table 7.4.3.1-39: ACK (S-CSCF to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip:pcscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

40. ACK (P-CSCF to UE) - see example in table 7.4.3.1-40 

P-CSCF forwards the ACK request to UE. 

Table 7.4.3.1-40: ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

7.4.3.2 UE-detected failure/resource failure (not provided) 

An example of this flow is not shown in the present document. 

7.4.3.3 Origination failure (not provided) 

An example of this flow is not shown in the present document. 

7.4.4 CS-T 

7.4.4.1 (CS-T) CS Networks termination (M0#2, S-S#3 assumed) 

Figure 7.4.4.1-1 shows the MGCF in the IM CN subsystem, which is a SIP endpoint that initiates and receives requests 
on behalf of the CS Networks and Media Gateway (MGW). Other nodes consider the signalling as if it came from a S- 
CSCF. The MGCF incorporates the network security functionality of the S-CSCF. 

Agreements between network operators may allow CS Networks termination in a network other than the originator's 
home network. This may be done, for example, to avoid long distance or international tariffs. 

This termination procedure can be used in either S-S#3 or S-S#4. 
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Figure 7.4.4.1-1 : CS Networks termination 

The CS Networks termination procedure is as follows: 

1 . INVITE (S-S to CS-T) - see example in table 7.4.4.1-1 

MGCF receives an INVITE request, through one of the origination procedures and via one of the S-CSCF to 
S-CSCF procedures. 

Table 7.4.4.1-1 : INVITE (S-S to CS-T) 

INVITE sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 
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Via: SIP/2. 0/UDP bgcf 1 .homel .net;branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel . net ; lr> 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: : a55 : b4 4 : c33 : d22 ] ; 

ecf=[5555::lff:2ee:3dd:4cc]; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: 

Contact: <sip: [5555: : aaa: bbb: ccc : ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

m=video RTP/AVP 99 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

P-Charging- Vector: The S-CSCF passes this header to the MGCF for charging. If S-CSCF and MGCP are in 

different networks (S-S#4), then orig-ioi is included here and the term-ioi would be included in the 
183 response. 

P-Charging-Function-Addresses: The S-CSCF inserts this header to provide the charging function addresses to the 
MGCF if S-CSCF and MGCF are in the same network (S-S#3). This header is not present when S- 
CSCF and MGCF are in different networks (S-S#4). 

Upon receiving the INVITE, the MGCF stores the following information about this session - see example in 
table 7.4.4.1 -lb. 



Table 7.4.4.1 -1b: Storage of information at MGCF 



I Request-URI : sip : +l-212-555-2222@homel . net ; user=phone 
[ From: <sip:userl_publicl@homel . net>; tag=171828 
: To: <tel:+l-212-555-2222>;tag=314159 
I Call-ID: Cb03a0s09a2sdfglkj490333 
: Cseq: 127 INVITE 
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SDP: The SDP contains the desired set of supported codecs from the session originator, as restricted by 

the originating network operator. The "m=" Hnes for the video media streams show a port number 
zero, which removes them from the negotiation. 

2. 100 Trying (CS-T to S-S) - see example in table 7.4.4.1-2 

MGCF may respond to the INVITE request with a 100 Trying provisional response. 

Table 7.4.4.1-2: 100 Trying (CS-T to S-S) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP bgcfl .homel . net;branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. H.248 Interaction to Create Connection 

MGCF initiates a H.248 interaction to pick an outgoing channel and determine media capabilities of the 
MOW. 

4. SS7:IAM 

Based on the continuity support of the outgoing channel selected, MGCF may decide to send an I AM 
message out to the CS Networks at this point. In case the outgoing channel does not support continuity 
indication, MGCF sends out an lAM message only in step 14. 

5. Possible bearer related negotiation takes place (in case BICC is used) 

6. 183 Session Progress (CS-T to S-S) - see example in table 7.4.4.1-6 

MGCF determines the subset of the media flows proposed by the originating endpoint that it supports, and 
responds with a 183 Session Progress response back to the originator. This response is sent via the S-CSCF 
to S-CSCF procedure. 

NOTE: in order to be able to send the lAM message at step 4, the MGCF has to select one media from the SDP 
received in INVITE. 

Table 7.4.4.1-6: 183 Session Progress (CS-T to S-S) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP bgcfl . homel . net ; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

P-As serf ed- Identity: <tel:+l-212-555-2222> 

P-Charging-Vector : 

Privacy: none 

From: 

To: <tel:-H-212-555-2222>; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: <sip:mgcfl .homel . net> 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
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c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m-video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 3 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



7. PRACK (S-S to CS-T) - see example in table 7.4.4.1-7 

The originating endpoint sends a PRACK request containing the final SDP to be used in this session, via the 
S-CSCF to S-CSCF procedure, to MGCF. 

Table 7.4.4.1-7: PRACK (S-S to CS-T) 

PRACK sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 128 PRACK 

Rack: 9021 127 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=vldeo RTP/AVP 99 

m-vldeo RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

8. 200 OK (CS-T to S-S) - see example in table 7.4.4.1-8 

MGCF acknowledges the PRACK request (8) with a 200 OK response. 

Table 7.4.4.1-8: 200 OK (CS-T to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 
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m=video RTP/AVP 99 

m-video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 3 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



9. H.248 Interaction to Modify Connection 



MGCF initiates a H.248 interaction to modify the connection established in step #3 and instruct MGW to 
reserve the resources necessary for the media streams. 

10. Resource Reservation 

MGW reserved the resources necessary for the media streams. 

1 1. UPDATE (S-S to CS-T) - see example in table 7.4.4,1-11 

When the originating endpoint has completed its resource reservation, it sends the UPDATE request to 
MGCF, via the S-CSCF to S-CSCF procedures. 

Table 7.4.4.1-11 : UPDATE (S-S to CS-T) 

UPDATE sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: <sip:userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 12 9 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

12. 200 OK (CS-T to S-S) - see example in table 7.4.4.1-12 

MGCF acknowledges the UPDATE request (11) with a 200 OK response. 

Table 7.4.4.1-12: 200 OK (CS-T to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 
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Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 



13.SS7:COT/IAM 

Based on the continuity support of the outgoing channel selected MGCF sends a lAM or COT message to 
the CS Networks. In case the outgoing channel supports continuity indication, MGCF has already sent out the 
lAM message in step 4, and at this point sends out a COT message. 

14. SS7: ACM/CPG 

The CS Networks establishes the path to the destination. In the present case the CS Networks responds with 
an ACM message containing a "subscriber free" indication, implying that the called party is being alerted. 

15. 180 (CS-T to S-S) - see example in table 7.4.4.1-15 

If the CS Network is alerting the destination user, MGCF indicates this to the calling party by a 180 Ringing 
provisional response. This response is sent via the S-CSCF to S-CSCF procedures. 

As the indication of called party being alerted ("subscriber free" indication) may not be available in ACM, 
the 180 Ringing is only sent when the indication is available. An ACM without the "subscriber free" 
indication will not trigger any SIP message. 

Table 7.4.4.1-15: 180 Ringing (CS-T to S-S) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP bgcf 1 .homel . net; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

Require: lOOrel 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip:mgcfl .homel . net> 

RSeq: 9022 

Content-Length: 

The 180 Ringing is used when the ACM has indicated that the called party is being alerted. 
16. PRACK (S-S to CS-T) - see example in table 7.4.4.1-16 

The originator acknowledges the 180 Ringing provisional response (15) with a PRACK request. 

Table 7.4.4.1-16: PRACK (S-S to CS-T) 

PRACK sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 
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Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 



17. 200 OK (CS-T to S-S) - see example in table 7.4.4.1-17 

MGCF acknowledges the PRACK request (16) with a 200 OK response. 

Table 7.4.4.1-17: 200 OK (CS-T to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

18.SS7:ANM 

When the called party answers, the CS Network sends an ANM message to the MGCF. 
19. H.248: Interaction to Modify Connection 

MGCF initiates a H.248 interaction to make the connection in the MGW bi-directional. 
20. 200 OK (CS-T to S-S) - see example in table 7.4.4.1-20 

MGCF sends a 200 OK final response along the signalling path back to the session originator. 

Table 7.4.4.1-20: 200 OK (CS-T to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP bgcfl .homel . net; branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: <sip:mgcfl .homel . net> 

Content-Length: 

21. ACK (S-S to CS-T) - see example in table 7.4.4.1-21 

The Calling party acknowledges the final response (20) with an ACK request. 

Table 7.4.4.1-21 : ACK (S-S to CS-T) 

ACK sip:+l-212-555-2222@home2.net; user=phone SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

Cseq: 127 ACK 

Content-Length: 

7.4.4.2 MGCF-detected failure/resource failure (not provided) 

An example of this flow is not shown in the present document. 
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7.4.4.3 Origination failure (not provided) 

An example of this flow is not shown in the present document. 

7.4.5 MT#1c 

7.4.5.1 (MT#1c) Mobile termination, roaming, without l-CSCF in home network 

providing configuration independence, terminating UE is busy, and not able 
or not willing to answer the call (M0#2, S-S#2 assumed) 

Figure 7.4.5.1 shows a termination procedure which applies to roaming subscribers when the home network operator 
does not desire to keep its internal configuration hidden from the visited network. The UE is located in a visited 
network, and determines the P-CSCF via the CSCF discovery procedure. During registration, the home network 
allocates the S-CSCF. 

When registration is complete, S-CSCF knows the name/address of P-CSCF, and P-CSCF knows the name/address of 
the UE. 



Home Network 



Visited Network 



S-CSCF 



1. INVITE 



-2. 100 Trying- 



P-CSCF 



3. Evaluation of initial filter 
criterias 



-11. 486 Busy Here- 
12. ACK 



-4. INVITE- 



-5. 100 Trying- 



-9. 486 Busy Here- 
10. ACK 



UE#2 



-6. INVITE- 



-7. 486 Busy Here- 
8. ACK 



Figure 7.4.5.1-1 :MT#1c 

Procedure MT#lc is as follows: 

1 . INVITE (S-S to MT#la) - see example in table 7.4.5.1-1 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 

Table 7.4.5.1-1 : INVITE (S-S to MT#1c) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip: scscf 2 .home2 . net; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

P-Asserted-Identity : "John Doe" <sip : userl_publicl@homel . net>, <tel : -M-212-555-llll> 
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P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 

To; <tel;+l-212-555-2222> 

Call- ID; Cb03a0s0 9a2sdfglkj4 90333 

Cseq; 127 INVITE 

Require; precondition 

Supported; lOOrel 

Contact; <sip; [5555; ; aaa;bbb; ccc ; ddd] > 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ;bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

2. 100 Trying (MT#lc to S-S) - see example in table 7.4.5.1-2 

S-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.4.5.1-2: 100 Trying (MT#1c to S-S) 

SIP/2.0 100 Trying 

Via; SIP/2. 0/UDP icscf 2_s .homel . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ;branch=z9hG4bKnashds7 

From; 

To; 

Call-ID; 

CSeq; 

Content-Length; 

3. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

4. INVITE (S-CSCF to P-CSCF) - see example in table 7.4.5.1-4 

S-CSCF remembers (from the registration procedure) the next hop CSCF for this UE. It forwards the 
INVITE to the P-CSCF. 

S-CSCF examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 



Table 7.4.5.1-4: INVITE (S-CSCF to P-CSCF) 



INVITE sip; [5555; ;eee;fff;aaa;bbb] SIP/2.0 

Via; SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s. homel. net ;branch=z9hG4bK871y 12. 1, SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 66 

Route ; <sip;pcscf2.visited2.net;lr> 

Record-Route; <sip; scscf 2 .home2 . net; lr>, <sip; scscf 1 .homel . net; lr>, <sip;pcscfl .homel . net; lr> 
P -Asserted- Identity ; 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
Privacy ; 
From; 
To; 
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Call-ID: 

Cseq: 

Require ; 

Supported: 

Contact : 

P-Called-Party-ID: <sip: user2_publicl@home2 . net> 

Content-Type : 

Content-Length: (...) 



P-Called-Party-ID: Includes the dialled URL with its parameters 
Route: Built from the Path header. 

Via:, Record-Route: S-CSCF adds itself 

5. 100 Trying (P-CSCF to S-CSCF) - see example in table 7.4.5.1-5 

P-CSCF responds to the INVITE request (4) with a 100 Trying provisional response. 

Table 7.4.5.1-5: 100 Trying (P-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

6. INVITE (P-CSCF to UE) - see example in table 7.4.5.1-6 

P-CSCF removes the Record-Route and Via headers, calculates the proper Route header to add to future 
requests, and saves that information without passing it to UE. P-CSCF forwards the INVITE request to the 
UE. 

Table 7.4.5.1-6: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards : 65 

P -Asserted- Identity : 

Privacy : 

P-Media-Authorization: 0020000100100101706466322e76697369746564322e6e6574000c02013331533134363231 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saves 
values. It inserts this as a branch value on its Via header. 



P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.visited2.net" with credentials "31814621". 

7. 486 Busy Here (UE to P-CSCF) - see example in table 7.4.5.1-7 

UE is contacted successfully but it is currently not willing or able to take additional sessions. The response 
MAY indicate a better time later to call in the Retry-After header. 

Table 7.4.5.1-7: 486 Busy Here (UE to P-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK361k21 . 1 

From; 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

8. ACK (P-CSCF to UE) - see example in table 7.4.5.1-8 

Upon receive the 486 response from the UE, P-CSCF sends ACK back to the UE. 

Table 7.4.5.1-8: ACK (P-CSCF to UE) 

ACK sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

9. 486 Busy Here (P-CSCF to S-CSCF) - see example in table 7.4.5.1-9 

P-CSCF forwards the 486 response to the S-CSCF. 

Table 7.4.5.1-9: 486 Busy Here (P-CSCF to S-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7) 
From: 

To: <tel:+l-212-555-2222>;tag=31415 9 
Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 
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10. ACK (S-CSCF to P-CSCF) - see example in table 7.4.5.1-10 
S-CSCF sends ACK to the P-CSCF. 

Table 7.4.5.1-10: ACK (S-CSCF to P-CSCF) 

ACK sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . IFrom: 

Route ; <sip:pcscf2.visited2.net;lr> 

To: 

Call-ID: 

CSeq: 

Content-Length: 

1 1. 486 Busy Here (MT#lc to S-S) - see example in table 7.4.5.1-11 

S-CSCF forwards the 486 Busy Here response to the originator, per the S-CSCF to S-CSCF procedure. Also 
indicates the voice mail address of the callee. 

Table 7.4.5.1-11 : 486 Busy Here (MT#1c to S-S) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP icscf2_s .homel .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 

12. ACK (S-S to MT#lc) - see example in table 7.4.5.1-12 

The S-CSCF of calling party responds to the 486 Busy Here response with an ACK request that is sent to S- 
CSCF via the S-CSCF to S-CSCF procedure. 

Table 7.4.5.1-12: ACK (S-S to MT#1c) 

ACK sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Route: <sip: scscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



7.4.6 MT#2a 

7.4.6.1 (MT#2a) Mobile termination, located in home network, terminating UE is 

busy, and not able or not willing to answer the call (M0#2, S-S#2 assumed) 

MT#2a flow is the same scenario as MT#lc with the difference that in MT#2a S-CSCF and P-CSCF are in the same 
network. For simplicity the detailed flow is not provided. 

7.4.7 MT#1e 

7.4.7.1 (MT#1e) Mobile termination, roaming, without l-CSCF in home network 

providing configuration independence, service is refused by S-CSCF when 
receiving INVITE request (M0#2, S-S#2 assumed) 
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Figure 7.4.7.1-1 shows a termination procedure, which applies to roaming subscribers when the home network operator 
does not desire to keep its internal configuration hidden from the visited network. The UE is located in a visited 
network, and determines the P-CSCF via the CSCF discovery procedure. During registration, the home network 
allocates the S-CSCF. 

When registration is complete, S-CSCF knows the name/address of P-CSCF, and P-CSCF knows the name/address of 
the UE. 



Home Network 



Visited 
Network 



S-CSCF 



-1. INVITE 

2. 100_ 

Trying 



P-CSCF 



3. Evaluation of initial 
filter criterias 



4. 403 
Forbidden 

—5. ACK — 



UE#2 



Figure 7.4.7.1-1 : Mobile termination, roaming, without l-CSCF in home network providing 
configuration independence, service is refused by S-CSCF when receiving INVITE request 

1. INVITE (S-S to MT#le) - see example in table 7.4.7.1-1 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 

Table 7.4.7.1-1 : INVITE (S-S to MT#1e) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route: <sip: scscf 2 .home2 . net; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. homel .net; lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 
Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 
Require: precondition 
Supported: lOOrel 

Contact: <sip: [5555 : aaa:bbb: ccc : ddd] > 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 
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a=curr:qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



2. 100 Trying (MT#le to S-S) - see example in table 7.4.7.1-2 

S-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.4.7.1-2: 100 Trying (MT#1e to S-S) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

4. 403 Forbidden (MT#le to S-S) - see example in table 7.4.7.1-4 

S-CSCF forwards the 403 Forbidden response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.4.7.1-4: 403 Forbidden (MT#1e to S-S) 

SIP/2.0 403 Forbidden 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7) 

From: 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call-ID: 

CSeq: 

Content-Length: 

5. ACK (S-S to MT#le) - see example in table 7.4.7.1-5 

The S-CSCF of calling party responds to the 403 Forbidden response with an ACK request that is sent to S- 
CSCF via the S-CSCF to S-CSCF procedure. 



Table 7.4.7.1-5: ACK (S-S to MT#1e) 



ACK sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1 

Route: <sip: scscf 2 .home2 . net; lr> 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



7.4.8 



Void. 



Mobile termination, roaming, terminal is out of racJio coverage 
(M0#2, S-S#2 assumed) 
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7.4.9 Mobile termination, unregistered subscriber 



7.4.9.1 



Introduction 



In the example information flows in the following sections, the subscriber receiving a terminating call is unregistered. 
Therefore, when the I-CSCF in the home network of the called subscriber queries the HSS for the location of the called 
subscriber, the HSS indicates that the subscriber is unregistered. 

In subclause 7.4.9.2, call setup does not proceed, as the subscriber does not have services related to unregistered state. 

In subclause 7.4.9.3, call setup proceeds and a temporary call instance is created at the callee's S-CSCF for the life of 
the call. This is to support services related to the unregistered state of the callee. 

7.4.9.2 Mobile termination, unregistered subscriber, no services related to 

unregistered state 

In the example information flow the subscriber is unregistered and the subscriber has no services related to unregistered 
state. This is shown in the following information flow (figure 7.4.9.2-1). 



Originating Network l-lome Network# 1 



Home Network#2 



Terminating Network 



S-CSCF#1 



— 1. INVITE — 
-2. lOOTrylng- 



3. Evalui 



te Filter 



Critf ria 



9. 404 User Not 
Reachable 

10. ACK 1 



I-CSCF 



4. INVITE 

—5. 100 Trying— 

7. 404 User Not 
Reachable 

8. ACK 



HSS 



6. Cx: User location query 



S-CSCF#2 



Figure 7.4.9.2-1 : Mobile termination, unregistered subscriber 

1 . INVITE (MO to S-S#la) - see example in table 7.4.9.2-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 7.4.9.2-1 : INVITE (MO to S-S#1a) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Route; <sip; scscf 1 .homel . net; lr> 
Record-Route ; <sip;pcscfl. visitedl. net;lr> 

P-Asserted-Identity ; "John Doe" <sip;userl_publicl@homel . net> 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 
To; <tel;+l-212-555-2222> 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
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Cseq: 127 INVITE 

Require; precondition 

Supported: lOOrel 

Contact: <sip: [5555: : aaa:bbb: ccc : ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 

o=- 2987933615 2987933615 



IN IP6 5555: :aaa:bbb:ccc:ddd 



c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 00 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video 3402 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



2. 100 Trying (S-S#la to MO) - see example in table 7.4.9.2-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.4.9.2-2: 100 Trying (S-S#1a to MO) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

3. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. 
For this example, assume no Application Server involvement. 
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4. INVITE (S-CSCF to I-CSCF) - see example in table 7.4.9.2-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, S-CSCF#1 forwards the INVITE request directly to I-CSCF in the destination network. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 

Table 7.4.9.2-4: INVITE (S-CSCF to I-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 ; ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 

Route : <sip : iscsf l_s . homel .net; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <s ip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "John Doe" <sip : userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel . net 
Privacy ; 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

5. 100 Trying (I-CSCF to S-CSCF) - see example in table 7.4.9.2-5 

I-CSCF responds to the INVITE request (4) by sending a 100 Trying provisional response to S-CSCF#1. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 285 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Table 7.4.9.2-5: 100 Trying (l-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

6. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
information that the subscriber is not currently registered and it does not have any service when the user is 
unregistered. 

For detailed message flows see 3GPP TS 29.228. 

Table 7.3.2.1-6a provides the parameters in the SIP INVITE request (flow 4), which are sent to the HSS. 

7. 404 User Not Reachable (I-CSCF to S-CSCF) - see example in table 7.4.9.2-7 

I-CSCF initiates a 404 User Not Reachable response to S-CSCF#1. 

Table 7.4.9.2-7: 404 User Not Reachable (I-CSCF to S-CSCF) 

SIP/2.0 404 User Not Reachable 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7) 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

8. ACK (S-CSCF to I-CSCF) - see example in table 7.4.9.2-8 

S-CSCF#1 responds to the I-CSCF with ACK. 

Table 7.4.9.2-8: ACK (S-CSCF to I-CSCF) 

ACK sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

9. 404 User Not Reachable (S-S#la to MO) - see example in table 7.4.9.2-9 

S-CSCF#1 forwards the 404 User Not Reachable to the originator, as per the originating procedure. 

Table 7.4.9.2-9: 404 User Not Reachable (S-S#1a to MO) 

SIP/2.0 404 User Not Reachable 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

10. ACK (MO to S-S#la) - see example in table 7.4.9.2-10 
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The originating endpoint sends the final acknowledgement to S-CSCF#1 by the origination procedures. 

Table 7.4.9.2-10: ACK (MO to S-S#1a) 



ACK tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 

From; 

To: 

Call-ID: 

Cseq: 127 ACK 

Content-Length: 



7.4.9.3 Mobile termination, unregistered subscriber, services related to unregistered 

state 

In the example information flow the subscriber is unregistered and the subscriber has services related to unregistered 
state. This is shown in the following information flow (figure 7.4.9.3-1). 
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Figure 7.4.9.3-1 : Mobile termination, unregistered subscriber with services 

1 . INVITE (MO to S-S#la) - see example in table 7.4.9.3-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 
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Table 7.4.9.3-1 : INVITE (MO to S-S#1a) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Route; <sip; scscf 1 .homel . net; lr> 
Record-Route ; <sip;pcscfl. visitedl. net;lr> 

P-Asserted-Identity ; "John Doe" <sip;userl_publicl@homel . net> 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 
To; <tel;+l-212-555-2222> 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 127 INVITE 
Require; precondition 
Supported; lOOrel 

Contact; <sip; [5555; ; aaa; bbb; ccc ; ddd] > 
Content-Type; application/sdp 
Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 34 00 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap: 99;MPV 

m=video 3402 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap; 99;MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

2. 100 Trying (S-S#la to MO) - see example in table 7.4.9.3-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.4.9.3-2: 100 Trying (S-S#1a to MO) 

SIP/2.0 100 Trying 

Via; SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To; 

Call-ID; 
CSeq; 
Content-Length; 
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3. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. 
For this example, assume no Application Server involvement. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 7.4.9.3-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, S-CSCF#1 forwards the INVITE request directly to to I-CSCF in the destination 
network. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 

Table 7.4.9.3-4: INVITE (S-CSCF to I-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 ; ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 

Route ; <sip : iscscf l_s . homel .net; lr> 

Record-Route : <sip:scscfl. homel .net;lr>, <sip;pcscfl. visitedl. net; lr> 
P-Asserted-Identity ; "John Doe" <sip;userl_publicl@homel . net, <tel ; +l-212-555-llll> 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] ; orig- 
ioi=homel . net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
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a=rtpmap: 96 G726-32/8000 

5. 100 Trying (I-CSCF to S-CSCF) - see example in table 7.4.9.3-5 

I-CSCF responds to the INVITE request (4) by sending a 100 Trying provisional response to S-CSCF#1. 

Table 7.4.9.3-5: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

6. Cx: User Registration Status Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
information that the user is not currently registered, but the user has services when the user is not registered. 

For detailed message flows see 3GPP TS 29.228. 

Table 7.3.2. l-6a provides the parameters in the SIP INVITE request (flow 4), which are sent to the HSS. 

Based on the CX response the I-CSCF selects an appropriate S-CSCF. 

7. INVITE (I-CSCF to S-CSCF) - see example in table 7.4.9.3-7 

Table 7.4.9.3-7: INVITE (I-CSCF to S-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7) 

Max-Forwards : 67 

Route: <sip: scscf 2 .home2 . net; lr> 

Record-Route : <sip:scscfl .homel . net; lr>, <sip:pcscfl. visitedl. net; lr> 

P-Asserted- Identity : 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
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8. 100 Trying (I-CSCF to S-CSCF) - see example in table 7.4.9.3-8 

I-CSCF responds to the INVITE request (4) by sending a 100 Trying provisional response to S-CSCF#1. 

Table 7.4.9.3-8: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

9. Cx: S-CSCF registration notification procedure 

The S-CSCF sends a query to the HSS to record the S-CSCF of the called user. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-7a provides the parameters in the INVITE request (flow 7) which are sent to the HSS 

10. Cx: User Profile Download procedure 

The S-CSCF sends a query to the HSS to determine the subscriber profile of the callee. The HSS responds 
with the profile. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-9a provides the parameters in the SIP INVITE request (flow 7), which are sent to the HSS. 

1 1 . Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. 

12. Successful session setup continues (not shown in the flow) 

The rest of the terminating session is setup as described in subclause 7.4.2 with the INVITE being 
transmitted from the S-CSCF#2 to the appropriate network entity (e.g. the INVITE may be forwarded to an 
application server). 

7.5 Sample multimedia signalling flows: addition of further 
media streams 



7.5.1 



Introduction 
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None. 

7.5.2 Sample multimedia signalling flow - addition of further media - 

originator and terminator are both roaming and operated by different 
networks 

Figure 7.5.2-1 shows a multimedia signalling flow for the addition of another media where the originator and terminator 
are both roaming and operated by different networks. Both networks are without 1-CSCF providing configuration 
independence. The UE has already established an IM session carrying voice and is generating an INVITE request to add 
video media to the already established IM session. 
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Figure 7.5.2-1 : Sample multimedia signalling flow - addition of further media 
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1 . INVITE (UEl to P-CSCFl) - see example in table 7.5.2-1 

UE#1 sends a SIP INVITE request, containing new SDP for the new video media and including the original 
SDP, to P-CSCFl, which is pcscfl.visitedl.net in its visited network. 

Table 7.5.2-1 INVITE (UEl to P-CSCFl) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Preferred-Identity: "John Doe" <tel : +l-212-555-llll> 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 132 INVITE 

Require : 

Supported: lOOrel 

Contact: <sip: [5555: : aaa: bbb: ccc : ddd] > 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907166275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

m=video 9544 RTP/AVP 31 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:31:H261/90000 

Request-URI: Contains the keyed number from the user. 

Via: Contains the IP address or FQDN of the originating UE. 

P-Asserted-Identity: The user provides a hint about the identity to be used for this session. 

From:/To:/Call-ID: Follow the recommendations of draft-ietf-sip-privacy-01, even though anonymity is not 
being requested for this session. 

Cseq: Is a random starting number. 

Contact: Is the SIP URL that contains the IP address or FQDN of the originating UE. 

2. 100 Trying (P-CSCFl to UEl) - see example in table 7.5.2-2 

P-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 7.5.2-2: 100 Trying (P-CSCFl to UEl) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. INVITE (P-CSCFl to S-CSCFl) - see example in table 7.5.2-3 
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The INVITE request is sent by the P-CSCF to the next hop scscfl.homel.net, which is in UE's home 
network. Because this a re-invite, so the I-CSCFl is not involved in sip transaction. 

Table 7.5.2-3: INVITE (P-CSCF1 to S-CSCF1) 

INVITE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : dSd: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length: (...) 

v= 
o = 
s = 
c = 

t = 



a= 
a= 

Route: P-CSCF knows the request routing from the previous sip transactions. 

Request-URI: The first component in the remembered Path header from Registration. 

4. 100 Trying (S-CSCFl to P-CSCFl) - see example in table 7.5.2-4 

S-CSCF sends the 100 Trying provisional response to P-CSCF. 

Table 7.5.2-4: 100 Trying (S-CSCFl to P-CSCFl) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

5. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. 

6. INVITE (S-CSCFl to S-CSCF2) - see example in table 7.5.2-6 

S-CSCF#1 sends the INVITE request to UE's serving CSCF-cscf2.home2.net, which is in the callee (UE2)'s 
home network. Because this is a re-invite, so the I-CSCF2 is not involved in the sip transaction. 
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S-CSCF#1 examines the media parameters, and removes any choices that the subscriber does not have 
authority to request. 

Table 7.5.2-6: INVITE (S-CSCF1 to S-CSCF2) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
P-Asserted- Identity: <sip : userl_publicl@homel .net>, <tel:+l-212-555-llll> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel . net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length: (...) 



7. 100 Trying (S-CSCF2 to S-CSCFl) - see example in table 7.5.2-7 

S-CSCFl receives a 100 Trying provisional response, as specified by the S-CSCF to S-CSCF procedures. 

Table 7.5.2-7: 100 Trying (S-CSCF2 to S-CSCFl) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

8. Evaluation of initial filter criterias 

S-CSCF2 validates the service profile of this subscriber and evaluates the initial filter criterias. 

9. INVITE (S-CSCF2 to P-CSCF2) - see example in table 7.5.2-9 

S-CSCF2 forwards the INVITE request tocallee's P-CSCF pcscf2.visited2.net which is in the UE2's visited 
network, called visited2.net 

S-CSCF#2 examines the media parameters, and removes any choices that the subscriber does not have 
authority to request. 
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Table 7.5.2-9: INVITE (S-CSCF2 to P-CSCF2) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v= 
o = 
s = 
c = 

t = 



10. 100 Trying (P-CSCF2 to S-CSCF2) - see example in table 7.5.2-10 
P-CSCF sends a 100 Trying provisional response back to S-CSCF2. 

Table 7.5.2-10: 100 Trying (P-CSCF2 to S-CSCF2) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

S IP /2. 0/UDP, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

1 1. INVITE (P-CSCF2 to UE2) - see example in table 7.5.2-11 

P-CSCF examines the media parameters, and removes any that the network operator decides, based on local 
policy, not to allow on the network. 

P-CSCF removes the Record-Route and Via headers, calculates the proper Route header to add to future 
requests, and saves that information without passing it to UE. 



Table 7.5.2-11 : INVITE (P-CSCF2 to UE2) 



INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards: 66 

Media-Authorization: 0020000100100101706466322e76697369746564322e6e6574000c020133315331343363233 

P-Asserted- Identity: 

Privacy : 
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From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy-Element 
generated by "pdf2.visited2.net" with credentials "31S14623". 

12. 100 Trying (UE2 to P-CSCF2) - see example in table 7.5.2-12 

P-CSCF receives a 100 Trying provisional response back to S-CSCF2. 

Table 7.5.2-12: 100 Trying (UE2 to P-CSCF2) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 . vlslted2 . net ; branch=z9hG4bKert23 . 8 

From: 

To: 

Call-ID: 

CSeq: 



13. 183 Session Progress (UE2 to P-CSCF2) - see example in table 7.5.2-13 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response. 

Table 7.5.2-13: 183 Session Progress response (UE2 to P-CSCF2) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . vlslted2 . net ; branch=z9hG4bK361k21 . 1 

Privacy: none 

From: 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: <slp: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9022 

Content-Type: appllcatlon/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

1=907166275 

m=audio 6544 RTP/AVP 97 
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b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

m=video 7544 RTP/AVP 31 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:31 H261/90000 



14. Authorize QoS Resources 

P-CSCF2 authorizes the resources necessary for this new media. 
15. 183 Session Progress (P-CSCF2 to S-CSCF2) - see example in table 7.5.2-15 
P-CSCF2 forwards the 183 Session Progress response to S-CSCF2. 

Table 7.5.2-15: 183 Session Progress (P-CSCF2 to S-CSCF2) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Asserted- Identity: <sip:user2_publicl@home2 . net> 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



16. 183 Session Progress (S-CSCF2 to S-CSCFl) - see example in table 7.5.2-16 

S-CSCF2 forwards the 183 Session Progress response to caller's S-CSCF. 

Table 7.5.2-16: 183 Session Progress (S-CSCF2 to S-CSCFl) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
P -Asserted- Identity: 
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P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

Privacy : 

From; 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c = 

t = 



17. 183 Session Progress (S-CSCFl to P-CSCFl) - see example in table 7,5.2-17 
S-CSCFl forwards the 183 Session Progress response to the caller's P-CSCF. 

Table 7.5.2-17: 183 Session Progress (S-CSCFl to P-CSCFl) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
P -Asserted- Identity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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18. Authorize QoS Resources 

P-CSCFl authorizes the resources necessary for this new media. 
19. 183 Session Progress (P-CSCFl to UEl) - see example in table 7.5.2-19 

P-CSCF forwards the 183 Session Progress response to the originating endpoint. 

Table 7.5.2-19: 183 Session Progress (P-CSCFl to UEl) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Media-Authorization: 0020000100100101706466312e76697369746564312e6e6574000c02013942563330373400 

P -Asserted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy-Element 
generated by "pdfl.visitedl.net" with credentials "9BV3074". 

20. PRACK (UEl to P-CSCFl) - see example in table 7.5.2-20 

The originating endpoint sends a PRACK request containing the final SDP to be used in this session to it's P- 
CSCF. 

Table 7.5.2-20: PRACK (UEl to P-CSCFl) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip:userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 133 PRACK 

Rack: 9022 132 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 
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a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

m=video 9544 RTP/AVP 31 

b=AS:54. 6 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:31 H261/90000 



21. PRACK (P-CSCFl to S-CSCFl) - see example in table 7.5.2-21 

P-CSCF adds a Route header, with the saved value from the previous response. P-CSCF identifies the proper 
saved value by the Request-URl. 

P-CSCF 1 forwards the PRACK request to S-CSCFl. 

Table 7.5.2-21 : PRACK (P-CSCFl to S-CSCFl) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 

Content-Type : 
Content-Length: (...) 



22. PRACK (S-CSCFl to S-CSCF2) - see example in table 7.5.2-22 
S-CSCFl forwards the PRACK request to S-CSCF2. 

Table 7.5.2-22: PRACK (S-CSCFl to S-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
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Content-Type : 
Content-Length : 



(...) 



23. PRACK (S-CSCF2 to P-CSCF2) - see example in table 7.5.2-23 
S-CSCF2 forwards the PRACK request to P-CSCF2. 

Table 7.5.2-23: PRACK (S-CSCF2 to P-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1 SIP/ 2 .0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Type : 

Content-Length : 



24. PRACK (P-CSCF2 to UE2) - see example in table 7.5.2-24 
P-CSCF2 forwards the PRACK request to callee UE2. 

Table 7.5.2-24: PRACK (P-CSCF2 to UE2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net;branch=z9hG4bK361k21 . 1 

Max-Forwards: 66 

From: 

To: 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



303 



ETSI TS 124 228 V5.3.0 (2002-12) 



Call-ID: 
Cseq: 

Rack: 

Content-Type : 
Content-Length : 



25. 200 OK (UE2 to P-CSCF2) - see example in table 7.5.2-25 

UE acknowledges the PRACK request with a 200 OK response. 

Table 7.5.2-25: 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 133 

Rack 

Content-Length : 



26. Resource Reservation 

UE2 initiates the reservation procedures for the new media. 
27. 200 OK (P-CSCF2 to S-CSCF2) - see example in table 7.5.2-27 
P-CSCF forwards the 200 OK response to S-CSCF. 

Table 7.5.2-27: 200 OK (P-CSCF2 to S-CSCF2) 

SIP/2.0 200 OK 
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Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1 SIP /2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



28. 200 OK (S-CSCF2 to S-CSCFl) - see example in table 7.5.2-28 

S-CSCF2 forwards the 200 OK response to the originator's S-CSCF, scscfl.homel.net. 

Table 7.5.2-28: 200 OK (S-CSCF2 to S-CSCF1) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



29. 200 OK (S-CSCFl to P-CSCFl) - see example in table 7.5.2-29 

S-CSCFl forwards the 200 OK response to the originator's P-CSCFl. 

Table 7.5.2-29: 200 OK (S-CSCFl to P-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
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To: 

Call-ID: 
CSeq: 
Content-Length : 



30. 200 OK (P-CSCFl to UEl) - see example in table 7.5.2-30 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.5.2-30: 200 OK (P-CSCFl to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



3 1 . Resource Reservation 

UEl initiates the reservation procedures for the new media. 

32. UPDATE (UEl to P-CSCFl) - see example in table 7.5.2-32 

When the resource reservation is completed, UE sends the UPDATE request to the terminating endpoint, via 
the signalling path established by the INVITE request. The request is sent first to P-CSCF. 

Table 7.5.2-32: UPDATE (UEl to P-CSCFl) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 
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From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 134 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

m=video 9544 RTP/AVP 31 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:31 H261/90000 



33. UPDATE (P-CSCFl to S-CSCFl) - see example in table 7.5.2-33 
P-CSCFl forwards the UPDATE request to S-CSCFl. 

Table 7.5.2-33: UPDATE (P-CSCFl to S-CSCFl) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-to]ten=43876559; flow-id=3 
Route: <sip: scscf 1 .Inomel . net; lr>, <sip: scscf 2 .]nome2 . net; lr>, <sip:pcscf 2 . visited2 . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Lengtln: (...) 



34. UPDATE (S-CSCFl to S-CSCF2) - see example in table 7.5.2-34 
S-CSCFl forwards the UPDATE request to S-CSCF2. 
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Table 7.5.2-34: UPDATE (S-CSCF1 to S-CSCF2) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 

Route: <sip: scscf2 .home2 . net; lr>, <sip:pcscf2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length: (...) 



35. UPDATE (S-CSCF2 to P-CSCF2) - see example in table 7.5.2-35 
S-CSCF2 forwards the UPDATE request to P-CSCF2. 

Table 7.5.2-35: UPDATE (S-CSCF2 to P-CSCF2) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK332b2 3. 1 S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Type : 

Content-Length : 
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36. UPDATE (P-CSCF2 to UE2) - see example in table 7.5.2-36 

P-CSCF forwards the UPDATE request to UE2. 

Table 7.5.2-36: UPDATE (P-CSCF2 to UE2) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



37. 200 OK (UE2 to P-CSCF2) - see example in table 7.5.2-37 

UE acknowledges the UPDATE request with a 200 OK response. 

Table 7.5.2-37: 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 
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38. 200 OK (P-CSCF2 to S-CSCF2) - see example in table 7.5.2-38 
P-CSCF2 forwards the 200 OK response to S-CSCF2. 

Table 7.5.2-38: 200 OK (P-CSCF2 to S-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1 SIP /2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



39. 200 OK (S-CSCF2 to S-CSCFl) - see example in table 7.5.2-39 

S-CSCF2 forwards the 200 OK response to the originator's serving CSCF. 

Table 7.5.2-39: 200 OK (S-CSCF2 to S-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



40. 200 OK (S-CSCFl to P-CSCFl) - see example in table 7.5.2-40 
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S-CSCFl forwards the 200 OK response to the P-CSCFl. 

Table 7.5.2-40: 200 OK (S-CSCFl to P-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

v= 
o= 
s = 
c= 

t = 



41. 200 OK (P-CSCFl to UEl) - see example in table 7.5.2-41 

P-CSCFl forwards the 200 OK response to UEl. 

Table 7.5.2-41 : 200 OK (P-CSCFl to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



42. Alerting 

UE#2 may optionally delay the session establishment in order to alert the subscriber to the incoming 
additional media. 

43. 180 Ringing (UE2 to P-CSCF2) - see example in table 7.5.2-43 
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Before proceeding with session establishment, the UE waits for two events. First, the resource reservation 
initiated in step #26 must complete successfully. Second, the resource reservation initiated by the originating 
endpoint must complete successfully (which is indicated by message #31 received by UE). The UE may now 
immediately accept the session or alert the destination subscriber of an incoming session attempt; if the latter 
it indicates this to the calling party by a 180 Ringing provisional response sent to P-CSCF. 

Table 7.5.2-43: 180 Ringing (UE2 to P-CSCF2) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net; branch=z9hG4bK361k21 . 1 

Require: lOOrel 

From: 

To: 

Call-ID: 

CSeq: 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] > 

RSeq: 9023 

Content-Length: 

44. 180 Ringing (P-CSCF2 to S-CSCF2) - see example in table 7.5.2-44 

P-CSCF2 forwards the 180 Ringing response to S-CSCF2. 

Table 7.5.2-44: 180 Ringing (P-CSCF2 to S-CSCF2) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1 SIP/ 2 .0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd) ; branch=z9hG4bKnashds7 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 

ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 

Require : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 

45. 180 Ringing (S-CSCF2 to S-CSCFl) - see example in table 7.5.2-45 

S-CSCF forwards the 180 Ringing response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.5.2-45: 180 Ringing (S-CSCF2 to S-CSCFl) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Require : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 

46. 180 Ringing (S-CSCFl to P-CSCFl) - see example in table 7.5.2-46 
S-CSCFl forwards the 180 Ringing response to the P-CSCFl. 

Table 7.5.2-46: 180 Ringing (S-CSCFl to P-CSCFl) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Require : 
From: 
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To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 



47. 180 Ringing (P-CSCFl to UEl) - see example in table 7.5.2-47 
P-CSCF forwards the 180 Ringing response to the UEl. 

Table 7.5.2-47: 180 Ringing (P-CSCFl to UEl) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Require : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 

48. Ringback 

UEl indicates to the originator that the media addition is being delayed due to alerting. Typically this 
involves playing a ringback sequence. 

49. PRACK (UEl to P-CSCFl) - see example in table 7.5.2-49 

The originating endpoint sends a PRACK request for the Ringing response to the terminator. 

Table 7.5.2-49: PRACK (UEl to P-CSCFl) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 135 PRACK 

Rack: 9023 132 INVITE 

Content-Length: 

50. PRACK (P-CSCFl to S-CSCFl) - see example in table 7.5.2-50 

P-CSCF adds a Route header, with the saved value from the previous response. P-CSCF identifies the proper 
saved value by the Request-URL 

P-CSCFl forwards the PRACK request to S-CSCFl. 

Table 7.5.2-50: PRACK (P-CSCFl to S-CSCFl) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf2 .home2 . net; lr>, <sip:pcscf2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

51. PRACK (S-CSCFl to S-CSCF2) - see example in table 7.5.2-51 
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S-CSCFl forwards the PRACK request to S-CSCF2. 

Table 7.5.2-51 : PRACK (S-CSCFl to S-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net;branch=z9hG4bK332b23 . 1 SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length: 

52. PRACK (S-CSCF2 to P-CSCF2) - see example in table 7.5.2-52 

S-CSCF2 forwards the PRACK request to P-CSCF2. 

Table 7.5.2-52: PRACK (S-CSCF2 to P-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1 SIP/ 2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

53. PRACK (P-CSCF2 to UE2) - see example in table 7.5.2-53 

P-CSCF2 forwards the PRACK request to callee UE2. 

Table 7.5.2-53: PRACK (P-CSCF2 to UE2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net; branch=z9hG4bK361k21 . 1 

Max-Forwards: &^ 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

54. 200 OK (UE2 to P-CSCF2) - see example in table 7.5.2-54 

UE2 acknowledges the PRACK request with a 200 OK response. 

Table 7.5.2-54: 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

55. 200 OK (P-CSCF2 to S-CSCF2) - see example in table 7.5.2-55 
P-CSCF2 forwards the 200 OK response to S-CSCF2. 
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Table 7.5.2-55: 200 OK (P-CSCF2 to S-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1 SIP/2 . 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

56. 200 OK (S-CSCF2 to S-CSCFl) - see example in table 7.5.2-56 

S-CSCF2 forwards the 200 OK response to the originator's serving CSCF. 

Table 7.5.2-56: 200 OK (S-CSCF2 to S-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

57. 200 OK (S-CSCFl to P-CSCFl) - see example in table 7.5.2-57 
S-CSCFl forwards the 200 OK response to the P-CSCFl. 

Table 7.5.2-57: 200 OK (S-CSCFl to P-CSCF1) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

58. 200 OK (P-CSCFl to UEl) - see example in table 7.5.2-58 
P-CSCFl forwards the 200 OK response to UEl. 

Table 7.5.2-58: 200 OK (P-CSCFl to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

59. 200 OK (UE2 to P-CSCF2) - see example in table 7.5.2-59 

UE acknowledges the Invite request with a 200 OK response. 

Table 7.5.2-59: 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net;branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 132 Invite 

Contact: <sip: [5555: : eee : f f f : aaa :bbb] > 
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Content-Type: application/sdp 
Content-Length: 

60. Approval of QoS Commit 

P-CSCF2 approves the commitment of the QoS resources for this additional media 

61. New media can start here 

62. 200 OK (P-CSCF2 to S-CSCF2) - see example in table 7.5.2-62 
P-CSCF2 forwards the 200 OK response to S-CSCF2. 

Table 7.5.2-62: 200 OK (P-CSCF2 to S-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1 SIP/2 .0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 

ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Type : 

Content-Length : 

63. 200 OK (S-CSCF2 to S-CSCFl) - see example in table 7.5.2-63 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 7.5.2-63: 200 OK (S-CSCF2 to S-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Type : 

Content-Length : 

64. 200 OK (S-CSCFl to P-CSCFl) - see example in table 7.5.2-64 

S-CSCFl forwards the 200 OK response to the P-CSCFl. 

Table 7.5.2-64: 200 OK (S-CSCFl to P-CSCF1) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Type : 
Content-Length : 

65. Approval of QoS Commit 

P-CSCFl approves the commitment of the QoS resources for this additional media. 
66. 200 OK (P-CSCFl to UEl) - see example in table 7.5.2-66 
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P-CSCF forwards the 200 OK response to the UEl. 

Table 7.5.2-66: 200 OK (P-CSCF1 to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Type : 

Content-Length : 

67. New media can start here 

68. ACK (UEl to P-CSCFl) - see example in table 7.5.2-68 

UEl forwards the ACK request to P-CSCFl. 

Table 7.5.2-68: ACK (UEl to P-CSCF1) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 132 ACK 

Contact: <sip: [5555: : aaa: bbb: ccc : ddd] > 

Content-Lengtli : 

69. ACK (P-CSCFl to S-CSCFl) - see example in table 7.5.2-69 

P-CSCFl adds a Route header, with the saved value from the previous response. P-CSCFl identifies the 
proper saved value by the Request-URL 

P-CSCFl forwards the ACK request to S-CSCFl. 

Table 7.5.2-69: ACK (P-CSCFl to S-CSCFl) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branc]i=z9]iG4bKnas]ids7 
Max-Forwards: 69 

Route: <sip: scscf 1 .liomel . net; lr>, <sip: scscf 2 .]iome2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Lengtli : 

70. ACK (S-CSCFl to S-CSCF2) - see example in table 7.5.2-70 

S-CSCFl forwards the ACK request to S-CSCF2. 

Table 7.5.2-70: ACK (S-CSCFl to S-CSCF2) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .liomel .net;branch=z9hG4bK332b23 . 1 SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branc]i=z9]iG4bKnas]ids7 
Max-Forwards: 68 

Route: <sip: scscf 2 .]iome2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Lengtli : 
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71. ACK (S-CSCF2 to P-CSCF2) - see example in table 7.5.2-71 

S-CSCF2 forwards the ACK request to P-CSCF2. 

Table 7.5.2-71 : ACK (S-CSCF2 to P-CSCF2) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1 SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

72. ACK (P-CSCF2 to UE2) - see example in table 7.5.2-72 

P-CSCF forwards the ACK request to UE2. 

Table 7.5.2-72: ACK (P-CSCF2 to UE2) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards: &^ 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

7.6 Error handling: session initiation (not provided) 

An example of this flow is not shown in the present document. 

8 Signalling flows for session release (non hiding) 

8.1 Introduction 

Void. 

8.2 Mobile terminal initiated session release 

Figure 8.2-1 shows a mobile terminal initiated IM CN subsystem application (SIP) session release. It is assumed that 
the session is active and that the bearer was established directly between the two visited networks (the visited networks 
could be the Home network in either or both cases). 
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Figure 8.2-1 : Mobile initiated session release 

1 SIP BYE (UE to P-CSCF) - see example in table 8.2-1 

One mobile party hangs up, which generates a SIP BYE request from the UE to the P-CSCF. 

Table 8.2-1 : SIP BYE (UE to P-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel . net> 

To: <tel:+l-212-555-2222>;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq: 153 BYE 

Content-Length: 



Request-URI: takes the value of the Contact header of the original received response. 

Via: takes the value of either the IP address or the FQDN of the originating UE. 

From:/To:/Call-ID: the example contents of the From header, the To header and Call-ID header are used to identify 
the session being cleared, and therefore are identical to those of the previously received response 
for that session, so that they include any tag parameters. 



CSeq: 



the content of the Cseq header must have a higher sequence number than the previous transaction. 
Here it is assumed that a Cseq value no greater than 152 has been previously used. 
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2 Release PDF 

Steps 2 and 3 may take place before or after Step 1 and in parallel with Step 4. The UE initiates the release 
of the bearer PDP context. The GPRS subsystem releases the PDP context. The IP network resources that had 
were reserved for the message receive path to the mobile for this session are now released. This is initiated 
from the GGSN. If RSVP was used to allocated resources, then the appropriate release messages for that 
protocol would invoked here. 

3 Rls. Response 

The GPRS subsystem responds to the UE. 

4 Remove resource reservation 

The P-CSCF removes the authorization for resources that had previously been issued for this endpoint for 
this session. This step will also result in a release indication to the GPRS subsystem to confirm that the IP 
bearers associated with the session have been deleted. 

5 SIP BYE (P-CSCF to S-CSCF) - see example in table 8.2-5 

The P-CSCF sends a SIP BYE request to the S-CSCF of the releasing party. 

Table 8.2-5: SIP BYE (P-CSCF to S-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscf 1 .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

6 SIP BYE (S-CSCF to S-CSCF) see example in table 8.2-6 

The SIP BYE request is sent from the S-CSCF to the S-CSCF of the network of the other party. 

Table 8.2-6: SIP BYE (S-CSCF to S-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd) ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: <sip: scscf2 .home2 . net; lr>, <sip:pcscf2 . visited2 . net; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

7 SIP BYE (S-CSCF to P-CSCF) - see example in table 8.2-7 

The SIP BYE request is forwarded directly to the P-CSCF. 

Table 8.2-7: SIP BYE (S-CSCF to P-CSCF) 

BYE sip:pcscf2. visited2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2.visited2.net;lr> 

From: 

To: 

Call-ID: 

CSeq: 
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Content-Length: 

8 Remove resource reservation 

The P-CSCF removes the authorisation for resources that had previously been issued for this endpoint for this 
session. This step also results in a release indication to the GPRS subsystem to confirm that the IP bearers 
associated with the UE#2 session have been deleted. 

9 SIP BYE (P-CSCF to UE) - see example in table 8.2-9 

The P-CSCF forwards the SIP BYE request on to the UE. 

Table 8.2-9: SIP BYE (P-CSCF to UE) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1; 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

10 200 OK (UE to P-CSCF) - see example in table 8.2-10 

The mobile responds with a 200 OK response, which is sent back to the P-CSCF. 

Table 8.2-10: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK361k21 . 1; 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

11 Release PDP 

Steps 1 2 and 1 3 may be done in parallel with step 1 1 . The Mobile initiates the release of the bearer PDP 
context. 

12 Rls response 

The GPRS subsystem releases the PDP context. The IP network resources that had were reserved for the 
message receive path to the mobile for this session are now released. This is initiated from the GGSN. If 
RSVP was used to allocated resources, then the appropriate release messages for that protocol would invoked 
here. 

13 200 OK (P-CSCF to S-CSCF) - see example in table 8.2-13 

The P-CSCF sends a 200 OK response to the S-CSCF directly. 

Table 8.2-13: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



14 200 OK (S-CSCF to S-CSCF) - see example in table 8.2-14 
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The S-CSCF of the other party forwards the 200 OK response to its local S-CSCF. 
Table 8.2-14: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

15 200 OK (S-CSCF to P-CSCF) - see example in table 8.2-15 

The S-CSCF of the releasing party forwards the 200 OK response to the P-CSCF of the releasing party. 

Table 8.2-15: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

16 200 OK (P-CSCF to UE) - see example in table 8.2-16 

The P-CSCF of the releasing party forwards the 200 OK response to the UE. 

Table 8.2-16: 200 OK (P-CCSF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



8.3 PSTN initiated session release (not provided) 

An example of this flow is not shown in the present document. 

8.4 Error inandling: session release (not provided) 

An example of this flow is not shown in the present document. 

9 Network initiated procedures (non hiding) 

An example of this flow is not shown in the present document. 

1 Procedures to enable enhanced multimedia services 
(non hiding) 
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10.1 Session hold and resume procedures 

10.1.1 Introduction 

This subclause gives signalling flows for the procedures for placing sessions on hold that were previously established 
by the mechanisms of clause 8, and resuming the session afterwards. Two cases are presented: mobile-to-mobile (UE- 
UE), and a UE-initiated hold of a UE-PSTN session. 

For a multimedia session, it is possible to place a subset of the media streams on hold while maintaining the others. 

1 0.1 .2 IVIobile-to-mobile session hold and resume procedures 

An IM session was previously established between an initiating UE and a terminating UE. Each of these UEs has an 
associated P-CSCF in the same network where they are currently located (either home or roaming), and a S-CSCF 
assigned in their home network . These functional elements co-operate to clear the session, and the procedures are 
independent of whether they are located in the home or visited networks. 

The hold and resume procedures are identical whether the UE that initiated the session also initiates the session-hold, or 
whether the UE that terminated the session initiates the session-hold. 

When a media stream has been placed on hold, it should not be resumed by any endpoint other than the one that placed 
it on hold. 

These procedures show only one combination of Mobile-Originated, Serving-to-Serving, and Mobile-Terminated 
procedures, MO#2, S-S#2, and MT#2. These procedures do not show the use of optional I-CSCFs. If an I-CSCF was 
included in the signalling path during the session establishment procedure, it would continue to be used in any 
subsequent signalling flows such as the ones described in this clause. Procedures at the I-CSCFs are identical to those 
described for the BYE, PRACK, and UPDATE requests and responses described in other clauses. 

As this flow does not require a user interaction at the remote end, it is realized with an UPDATE request. 

The procedures for placing a media stream on hold, and later resuming the media stream, are as shown in figure 10.1.2- 
1: 
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UE#1 



1. stop media flow 



2. UPDATE 
(Hold) 



-12. 200OK- 



13. UPDATE 
(Resume) 



-23. 200 OK- 



24. Resume media flow 



P-CSCF#1 S-CSCF#1 



3. UPDATE 
(Hold) 



-11. 200 OK - 



14. UPDATE 
(Resume) 



-22. 200 OK- 



4. UPDATE 
(Hold) 



-10. 200 OK - 



15. UPDATE 
(Resume) 



-21. 200 OK - 



S-CSCF#2 P-CSCF#2 



5. UPDATE 
(Hold) 



-9. 200OK- 



16. UPDATE 
(Resume) 



-20. 200 OK- 



^ 8. 200OK- 



UE#2 



6. UPDATE 
(Hold) 



7. Stop media flow 



17. UPDATE 
(Resume) 



18. Resume media flow 



-19. 200OK- 



Figure 10.1.2-1 : Mobile to mobile session hold and resume 

Signalling flow procedures are as follows: 

1. Stop Media Flow 

UE#1 detects a request from the subscriber to place a media stream on hold. UE#1 stops sending the media 
stream to the remote endpoint, but keeps the resources for the session reserved. 

2. UPDATE(Hold) (UE to P-CSCF) - see example in table 10.1.2-2 

UE#1 sends a Hold request to its proxy, P-CSCF#1. 

Table 10.1.2-2: UPDATE(Hold) (UE to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip : userl_publicl@homel .net 

To: tel: +1-212-555-2222; tag=3 14 15 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
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Request-URI: Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Via: Contains the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

Contact: Is the SIP URL that contains the IP address or FQDN of the originating UE. 

SDP The sendrecv media stream is placed on hold by changing it to inactive media stream, and 

no media is sent to the far end. 

3. UPDATE (Hold) (P-CSCF to S-CSCF) - see example in table 10.1.2-3 

P-CSCF adds a Route header, with the saved value from the previous 200 (OK) response. 

P-CSCF#1 forwards the Hold request to S-CSCF#1. 

Table 10.1.2-3: UPDATE(Hold) (P-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
P-Charging-Vector : icid-value=a834bcl92a44; icid-generated-at= [5555 : : e9e : d8d: c7c : b6b] 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



Route: Saved from the 200 (OK) response to the initial INVITE 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

4. UPDATE(Hold) (S-CSCF to S-CSCF) - see example in table 10.1.2-4 

S-CSCF#1 forwards the Hold request to S-CSCF#2. 

Table 10.1.2-4: UPDATE(Hold) (S-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-forwards: 68 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 
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P-Charging- Vector: If the two S-CSCF entities are located in different networks, then the orig-ioi parameter would 
be included (not shown). 

5. UPDATE(Hold) (S-CSCF to P-CSCF) - see example in table 10.1.2-5 

S-CSCF#2 forwards the Hold request to P-CSCF#2. 

Table 10.1.2-5: UPDATE(Hold) (S-CSCF to P-CSCF) 

UPDATE sip: [5555: : eee : f f f : aaa : bbb] 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-forwards : 67 

Route: sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



6. UPDATE(Hold) (P-CSCF to UE) - see example in table 10.1.2-6 

P-CSCF#2 forwards the Hold request to UE#2. 

Table 10.1.2-6: UPDATE(Hold) (P-CSCF to UE) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

Max-forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



Via: 



P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 
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7. Stop Media flow 

UE#2 stops sending the media stream to the remote endpoint, but keeps the resources for the session 
reserved. 

8. 200-OK (UE to P-CSCF) - see example in table 10.1.2-8 

UE#2 acknowledges receipt of the Hold request (6) with a 200 (OK) final response, sent to P-CSCF#2. 

Table 10.1.2-8: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ;branch=z9hG4bK556g98 . 5 

From; 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP6 5555 : : eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 6402 RTP/AVP 97 

b=AS:25.4 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

SDP: Since the media stream was offered as inactive, it is marked as inactive in the response. 

9. 200-OK (P-CSCF to S-CSCF) - see example in table 10.1.2-9 

P-CSCF#2 forwards the 200 OK final response to S-CSCF#2. 

Table 10.1.2-9: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



P-CSCF restores the Via headers and Record-Route headers from the branch value in its Via. 
10. 200-OK (S-CSCF to S-CSCF) - see example in table 10.1.2-10 

S-CSCF#2 forwards the 200 OK final response to S-CSCF#1. 

Table 10.1.2-10: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 
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Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



1 1. 200-OK (S-CSCF to P-CSCF) - see example in table 10.1.2-11 

S-CSCF#1 forwards the 200 OK final response to P-CSCF#1. 

Table 10.1.2-11: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



12. 200-OK (P-CSCF to UE) - see example in table 10.1.2-12 

P-CSCF#1 forwards the 200 OK final response to UE#1. 

Table 10.1.2-12: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

13. UPDATE(Resume) (Ue to P-CSCF) - see example in table 10.1.2-13 

UE#1 detects a request from the subscriber to resume the media stream previously placed on hold. UE#1 
sends a Resume request to its proxy, P-CSCF#1. 

Table 10.1.2-13: UPDATE(Resume) (UE to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip:userl_publicl@homel . net; tag=171828 

To: tel: +1-212-555-2222; tag=3 14 15 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

Request-URI: Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Via: Contains the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

Contact: The IP address or FQDN of the originating UE. 

SDP: Same SDP as negotiated during the session setup, restores the sendrecv media stream. 

14. UPDATE(Resume) (P-CSCF to S-CSCF) - see example in table 10.1.2-14 

P-CSCF adds a Route header, with the saved value from the previous 200 (OK) response. 
P-CSCF#1 forwards the Resume request to S-CSCF#1. 

Table 10.1.2-14: UPDATE(Resume) (P-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
P-Charging-Vector : icid-value=a834bcl92a45 ; icid-generated-at= [5555 : : e9e : d8d: c7c : b6b] 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



t = 
m= 
b= 
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Route: 



Saved from the 200 (OK) response to the initial INVITE. 



P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

15. UPDATE(Resume) (S-CSCF to S-CSCF) - see example in table 10.1.2-15 

S-CSCF#1 forwards the Resume request to S-CSCF#2. 

Table 10.1.2-15: UPDATE(Resume) (S-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-forwards: 68 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



16. UPDATE(Resume) (S-CSCF to P-CSCF) - see example in table 10.1.2-16 

S-CSCF#2 forwards the Resume request to P-CSCF#2. 

Table 10.1.2-16: UPDATE(Resume) (S-CSCF to P-CSCF) 

UPDATE sip: [5555: : eee : f f f : aaa : bbb] 

Via: SIP/2. 0/UDP scscf 2 . home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-forwards : 67 

Route: sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



17. UPDATE(Resume) (P-CSCF to UE) - see example in table 10.1.2-17 
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P-CSCF#2 forwards the Resume request to UE#2. 

Table 10.1.2-17: UPDATE(Resume) (P-CSCF to UE) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

Max-forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 

c = 

t = 



a= 
a= 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

18. Resume media flow 

UE#2 resumes sending the media stream to the remote endpoint. 
19. 200-OK (UE to P-CSCF) - see example in table 10.1.2-19 

UE#2 acknowledges receipt of the Resume request (17) with a 200 (OK) final response, sent to P-CSCF#2. 

Table 10.1.2-19: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555 : : eee : f f f : aaa:bbb 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 6402 RTP/AVP 97 

b=AS:25.4 

a=sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

20. 200-OK (P-CSCF to S-CSCF) - see example in table 10.1.2-20 

P-CSCF#2 forwards the 200 OK final response to S-CSCF#2. 

Table 10.1.2-20: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .home 1 . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 
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Content-Length : 



P-CSCF restores the Via headers from the branch value in its Via. 
21. 200-OK (S-CSCF to S-CSCF) - see example in table 10.1.2-21 

S-CSCF#2 forwards the 200 OK final response to S-CSCF#1. 

Table 10.1.2-21: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



22. 200-OK (S-CSCF to P-CSCF) - see example in table 10.1.2-22 

S-CSCF#1 forwards the 200 OK final response to P-CSCF#1. 

Table 10.1.2-22: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



23. 200-OK (P-CSCF to UE) - see example in table 10.1.2-23 

P-CSCF#1 forwards the 200 OK final response to UE#1. 
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Table 10.1.2-23: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 

c= 

t = 



24. UE Resume Media Flow 

1 0.1 .3 Mobile-initiated Inold and resume of a mobile-PSTN session 

An IM session was previously established between an initiating UE and a MGCF acting as a gateway for a session 
terminating on the PSTN, or between an initiating MGCF acting as a gateway for a session originating on the PSTN to a 
terminating UE. The UE has an associated P-CSCF in the same network where it is currently located (either home or 
roaming), an S-CSCF assigned in its home network, and a BGCF that chooses the MGCF. These functional elements 
co-operate to clear the session, and the procedures are independent of whether they are located in the subscriber's home 
or visited networks. Therefore there is no distinction in this clause of home network vs. visited network. 

The session hold and resume procedure is similar whether the UE initiated the session to the PSTN, or if the PSTN 
initiated the session to the UE. The only difference is the optional presence of the BGCF in the case of a session 
initiated by the UE. The BGCF might or might not be present in the signalling path after the first INVITE is routed. 

These procedures show only one combination of Mobile-Originated, Serving-to-Serving, and Mobile-Terminated 
procedures, MO#2, S-S#3, and CS-T. These procedures do not show the use of optional I-CSCFs, or the use of the 
BGCF in achieving network configuration independence. If an I-CSCF/BGCF was included in the signalling path 
during the session establishment procedure, it would continue to be used in any subsequent signalling flows such as the 
ones described in this clause. Procedures at the I-CSCFs are identical to those described for the BYE, PRACK, and 
UPDATE requests and responses described in other clauses. 

As this flow does not require a user interaction at the remote end, it is realized with an UPDATE request. 

The procedures for placing a media stream on hold, and later resuming the media stream, are as shown in figure 10.1.3- 
1: 
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UE 



P-CSCF 



1. stop media flow 



2. UPDATE 

(Hold) 



-8. 200 OK- 



9. UPDATE 

(Resume) 



-15. 200OK- 



16. Resume media flow 



S-CSCF 



3. UPDATE_ 
(Hold) 



-7. 200OK- 



10. UPDATE 
(Resume) 



-14. 200OK- 



BGCF 



4. UPDATE_ 
(Hold) 



-6. 200OK- 



11. UPDATE 
(Resume) 



-13. 200 OK - 



MGCP 



MGW 



PSTN 



5. H.248 interaction to 
stop media flow 



12. H.248 interaction to 
resume media flow 



Figure 10.1.3-1 : Mobile to PSTN session hold and resume 

Signalling flow procedures are as follows: 

1. Stop Media Flow 

UE#1 detects a request from the subscriber to place a media stream on hold. UE#1 stops sending the media 
stream to the remote endpoint, but keeps the resources for the session reserved. 

2. UPDATE (Hold) (UE to P-CSCF) - see example in 10.1.3-2 

UE sends a Hold request to its proxy, P-CSCF. 

Table 10.1.3-2: UPDATE (Hold) (UE to P-CSCF) 

UPDATE sip:mgcfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

From; sip ; userl_publicl(3homel . net ; tag=171828 

To; tel;-H-2 12-555-2222 ;tag=3 14 15 9 

Call- ID; Cb03a0s0 9a2sdfglkj4 90333 

Cseq; 130 UPDATE 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=- 2987933615 2987933616 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS;25.4 

a=inactive 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 



Request-URI: 



Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 
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Via: Contains the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

Contact: The IP address or FQDN of the originating UE. 

SDP The sendrecv media stream is placed on hold by changing it to inactive media stream, and 

no media is sent to the far end. 

3. UPDATE (Hold) (P-CSCF to S-CSCF) - see example in table 10.1.3-3 

P-CSCF adds a Route header, with the saved value from the previous 200 (OK) response. 

P-CSCF forwards the Hold request to S-CSCF. 

Table 10.1.3-3: UPDATE (Hold) (P-CSCF to S-CSCF) 

UPDATE sip:mgcfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 
Route; sip; scscfl .homel . net; Ir 

P-Charging-Vector ; icid-value=a834bcl92a44; icid-generated-at= [5555 ; ; e9e ; d8d; c7c ; b6b] 
From; 
To; 

Call-ID; 
Cseq; 

Content-Type ; 
Content-Length ; 



Route: Saved from the 200 (OK) response to the initial INVITE. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

4. UPDATE (Hold) (S-CSCF to MGCF) - see example in table 10.1.3-4 

S-CSCF forwards the Hold request to MGCF. 

Table 10.1.3-4: UPDATE (Hold) (S-CSCF to MGCF) 

UPDATE sip;mgcfl. homel. net SIP/2.0 

Via; SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ;branch=z9hG4bKnashds7 

Max-Forwards; 68 

P-Charging-Vector ; 

From; 

To; 

Call-ID; 

Cseq; 

Content-Type ; 

Content-Length ; 
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5. H.248 Interaction to Stop Media flow 

MGCF initiates a H.248 interaction with MGW instructing it to stop sending the media stream, but to keep 
the resources for the session reserved. 

6. 200-OK (MGCF to S-CSCF) - see example in table 10.1.3-6 

MGCF acknowledges receipt of the Hold request (4) with a 200 (OK) final response, sent to S-CSCF. 

Table 10.1.3-6: 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP6 5555 :: eee : fff : aaa :bbb 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxf rames=2 

SDP: Since the media stream was offered as inactive, it is marked as inactive in the response. 

7. 200-OK (S-CSCF to P-CSCF) - see example in table 10.1.3-7 

S-CSCF forwards the 200 OK final response to P-CSCF. 

Table 10.1.3-7: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



8. 200-OK (P-CSCF to UE) - see example in table 10.1.3-8 
P-CSCF forwards the 200 OK final response to UE. 
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Table 10.1.3-8: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 

c= 

t = 



9. UPDATE (Resume) (UE to P-CSCF) - see example in table 10.1.3-9 

UE detects a request from the subscriber to resume the media stream previously placed on hold. UE sends a 
Resume request to its proxy, P-CSCF. 

Table 10.1.3-9: UPDATE (Resume) (UE to P-CSCF) 

UPDATE sip:mgcfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip:userl_publicl@homel . net; tag=171828 

To: tel: +1-212-555-2222; tag=3 14 15 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

Request-URI: Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Via: Contains the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

SDP Same SDP as negotiated during the session setup, restores the sendrecv media stream. 

10. UPDATE (Resume) (P-CSCF to S-CSCF) - see example in table 10.1.3-10 

P-CSCF adds a Route header, with the saved value from the previous 200 (OK) response. 
P-CSCF forwards the Resume request to S-CSCF. 

Table 10.1.3-10: UPDATE(Resume) (P-CSCF to S-CSCF) 

UPDATE sip:mgcfl. homel.net SIP/2.0 
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Via: SIP/2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 
Route; sip; scscfl .homel . net; Ir 

P-Charging-Vector ; icid-value=a834bcl92a45; icid-generated-at= [5555 ; ; e9e ; d8d; c7c ;b6b] 
From; 
To; 

Call-ID; 
Cseq; 

Content-Type ; 
Content-Length ; 

v= 
o = 
s = 
c = 

t = 



Route: Saved from the 200 (OK) response to the initial INVITE. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

1 1. UPDATE(Resume) (S-CSCF to MGCF) - see example in table 10.1.3-11 

S-CSCF forwards the Resume request to MGCF. 

Table 10.1.3-11: UPDATE(Resume) (S-CSCF to MGCF) 

UPDATE sip;mgcfl. homel. net SIP/2.0 

Via; SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 68 

P-Charging-Vector ; 

From; 

To; 

Call-ID; 

Cseq; 

Content-Type ; 

Content-Length ; 

v= 
o = 
s = 
c = 
t = 
m= 
b= 
a= 
a= 
a= 

12. H.248 Interaction to Resume media flow 

MGCF initiates a H.248 interaction with MGW instructing it to resume sending the media stream. 

13. 200 OK (MGCF to S-CSCF) - see example in table 10.1.3-13 

MGCF acknowledges receipt of the Resume request (11) with a 200 (OK) final response, sent to S-CSCF. 

Table 10.1.3-13: 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

From; 

To: 
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Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v=0 

o=- 2987933615 2987933617 IN IP6 5555 :: eee : Iff : aaa :bbb 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 6402 RTP/AVP 97 

b=AS:25.4 

a=sendrecv 

a=rtpmap:97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 



14. 200 OK (S-CSCF to P-CSCF) - see example in table 10.1.3-14 

Table 10.1.3-14: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



15. 200 OK (P-CSCF to UE) - see example in table 10.1.3-15 
P-CSCF forwards the 200 OK final response to UE. 

Table 10.1.3-15: 200 OK (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



16. Resume Media Flow 

UE resumes sending the media stream to the remote endpoint. 
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1 0.2 Initiating and destination party identification 

10.2.1 Introduction 

When the UE (or MGCF) initiates a session in the IM CN subsystem, it determines, based on preferences of the 
initiating user, whether its identity is to be made available to the destination, or to remain anonymous. Three cases are 
distinguished: 

1. The initiating user desires his/her identity to be anonymous. 

2. The initiating user desires to be identified as the initiator of the session. 

3. The initiating user did not state a preference for this session. 

The values of the headers "From", "To", "Call-ID", "Remote-Party-ID" and "RPID-Privacy" are based on the decision 
above. 

When the UE (or MGCF) receives an incoming session request in the IM CN subsystem, it determines, based on 
preferences of the destination user, whether its identity is to be made available to the initiator or to remain anonymous. 
Three cases are distinguished: 

1. The destination user desires his/her identity to be anonymous. 

2. The destination user desires to be identified as the destination of the session. 

3. The destination user did not state a preference for this session. 

The values of the headers "Remote-Party-ID" and "RPID-Privacy" are based on the decision above. 
The rules for processing the header values at a proxy are given in draft-ietf-sip-privacy-04. 

1 0.2.2 IM sessions with session initiator desiring anonymity 

If the initiating user desires the session to be anonymous, the following rules are followed in generating header values: 



From: 


UE provides an anonymous username . 


To: 


If a telephone number is used in the addr-spec, the UE provides a tel URL containing a 
full E.1 64 number including the country code. 


Contact: 


The userinfo is either empty, or set to anonymous. The hostname is an IP address rather 
than an FQDN. 


Remote-Party-ID: 


UE includes the subscriber identity and URL in the Remote-Party-ID header value 


RPID-Privacy: 


UE includes the tag "privacy=fuH" in the RPID-Privacy header value 



An example of an initial INVITE request following the rules for an anonymous session is given in table 10.2.2-1. This 
revised information would appear as step #1 of MO#la (subclause 7.2.2), MO#lb (subclause 17.2.2), MO#2 
(subclause 7.2.3), and step #4 of CS-O (subclause 7.2.4). 

Table 10.2.2-1 : INVITE (Anonymous session) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Remote-Party-ID: "John Doe" <tel : +l-212-555-llll> 

RPID-Privacy : privacy=full; party=calling 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 
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v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

From: Contains a cryptographically random identifier for the userinfo, and a non-identifying hostname 

("localhost") for the hostname. Username is empty. 

To: Contains a cryptographically random identifier for the userinfo, distinct from the value of the From 

header, and a non-identifying hostname ("localhost") for the hostname. Username is empty. 

The values of From, To, Call-ID, and Remote-Party- ID, as given above, are carried through the INVITE sequence, 
through the S-CSCF serving the destination subscriber. When S-CSCF#2 forwards the INVITE request to the 
termination procedure (step #1 1 of S-S#la, step #13 of S-S#lb, step#l 1 of S-S#2, step#4 of MT#la, step#4 of MT#lb, 
step#4 of MT#2), the Remote-Party-ID header is updated with a private URL. An example of this INVITE request is 
given in table 10.2.2-2. 

Table 10.2.2-2: INVITE (S-S to MT) 

INVITE tel:+l-212-555-22222 SIP/2.0 
Max-Forwards; 69 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Route; sip;pcscf 2 .home2 . net; Ir 

Record-Route; sip; scscf 2 .home2 . net; Ir, sip; scscf 1 .homel . net; Ir 
Remote-Party-ID ; 
RPID-Privacy ; 
P-Charging-Vector ; 
From; 
To; 

Call-ID; 
Cseq; 

Supported; 
Require ; 
Contact ; 
Content-Type ; 
Content-Length ; 
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Remote-Party-ID: Contains a cryptographically random identifier for the userinfo, generated from the 

originating subscriber information, and the hostname identifying the S-CSCF that generated 
the userinfo string. Username is empty. 

When an I-CSCF is used to maintain configuration independence, it may (based on operator preferences) update the 
Remote-Party-ID header in order to hide the S-CSCF address. This occurs in MT#lb step #5. If so, it generates a new 
private URL with its own hostname. An example of this INVITE request is given in table 10.2.2-3. 

Table 10.2.2-3: INVITE (I-CSCF to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
Route: sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip: scscf2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscf 1 .homel . net; Ir 
Supported: 
Require : 

Remote-Party- ID: <sip: Token (token (tel: +1-212-555-1111) @scscf2 .home2 .net; 
user=private) @icscf .home2 . net; tokenized-by=home2 . net> 
RPID-Privacy : 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Content-Type : 
Content-Length : 

v= 
o = 
s = 
c= 

t = 



Remote-Party-ID: Contains a cryptographically random identifier for the userinfo, generated from the 

originating subscriber information, and the hostname identifying the I-CSCF that generated 
the userinfo string. Username is empty. 



1 0.2.3 IM sessions without initiator preference for anonymity 

If the initiating user did not state a preference for whether the session be anonymous, local policies and regulations may 
force the network operator to make it anonymous. Therefore, the following rules are followed in generating header 
values: 



From: 


UE provides any of the registered public user identities allocated to the user. 


To: 


If a telephone number is used in the addr-spec, the UE provides a tel URL containing 
anE.164 number. Otherwise, the UE provides the URI of the destination user. 


Remote-Party-ID: 


UE includes the subscriber identity and URL in the Remote-Party-ID header value. 


RPID-Privacy: 


The UE may specify the tag "privacy=off" in the RPID-Privacy header value 



An example of an initial INVITE request following the rules for an unspecified session is given in table 10.2.3-1 . 
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Table 10.2.3-1 : INVITE (Unspecified session) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Remote-Party-ID: "John Doe" <tel : +l-212-555-llll> 

RPID-Privacy : privacy=of f ; party=calling 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa:bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

From: Contains a cryptographically random identifier for the userinfo, and a non-identifying hostname 

("localhost") for the hostname. Username contains a string that does not identify the subscriber. 

To: Contains a cryptographically random identifier for the userinfo, distinct from the value of the From 

header, and a non-identifying hostname ("localhost") for the hostname. Username is empty. 

The values of From, To, Remote-Party-ID and RPID-Privacy, as given above, are carried through the INVITE 
sequence, through the S-CSCF serving the destination subscriber. 

Based on local policy or regulatory requirements, the S-CSCF serving the destination subscriber may either allow the 
identification information to be given to the destination (by following the example in subclause 10.2.2), or may restrict 
it (by following the example in subclause 10.2.1). 

1 0.2.4 IM sessions with destination requesting privacy 

If the destination user desires the session to be private, the UE indicates this in the value of the RPID-Privacy header in 
the first non-100 response to the initial INVITE. An example of this response from UE to P-CSCF (step#8 of MT#la, 
step#10 of MT#lb, step#8 of MT#2), is given in table 10.2.4-1. 

Table 10.2.4-1 : 183 Session Progress (UE to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK523r01 . 2 

Record-Route : 

Remote-Party-ID: "John Smith" <tel : +l-212-555-2222> 

RPID-Privacy : privacy=full; party=called 

From: 

To: tel:+l-212-555-2222; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 
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o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 



Remote-Party-ID: 



RPID-Privacy: 



Identifies the answering subscriber. It contains the public user identity, and the name of the 
answering party. 

The tag "privacy=fall" is appended to indicate full privacy is requested. 



The value of the Remote-Party-ID and RPID-Privacy header is carried through the 183-Session-Progress sequence, to 
the S-CSCF serving the initiating subscriber. When S-CSCF#1 forwards the 183-Session-Progress response to the 
originating procedure (step#16 of S-S#la, step#19 of S-S#lb, step#16 of S-S#2, also step#9 of MO#la, step#ll of 
MO#lb, step#9 of MO#2), the Remote-Party-ID header is updated with a private URL. An example of this 183- 
Session-Progress response is given in table 10.2.4-2. 

Table 10.2.4-2: 183 Session Progress (S-SCSF to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 

Remote-Party- ID ; <sip; token (tel: +1-2 12-555-2222 )@scscfl. homel .net; user=private> 
RPID-Privacy: 
Require : 

P-Charging-Vector ; 
P-Charging-Function-Addresses : 
From: 
To: 

Call-ID: 
CSeq: 

Require: lOOrel 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



Remote-Party-ID: 



Contains a cryptographically random identifier for the userinfo, generated from the 
originating subscriber information, and the hostname identifying the S-CSCF that generated 
the userinfo string. Username is empty. 



When an I-CSCF is used to maintain configuration independence, it may (based on operator preferences) update the 
Remote-Party-ID header in order to hide the S-CSCF address. This occurs in MO#lb step #12. If so, it generates a new 
private URL with its own hostname. An example of this INVITE request is given in table 10.2.4-3. 
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Table 10.2.4-3: 183 Session Progress (S-SCSF to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route : 

Remote-Party- ID: <sip: Token (token (tel:+l-212-555-2222) @scscf 1 .homel . net, ■ 
user=private) @icscf .homel . net; tokenized-by=homel . net> 
RPID-Privacy : 
Require ; 

P-Charging-Vector : 
P-Charging-Function-Addresses : 
From; 
To: 

Call-ID: 
CSeq: 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c = 

t = 



Remote-Party-ID: Contains a cryptographically random identifier for the userinfo, generated from the 

originating subscriber information, and the hostname identifying the I-CSCF that generated 
the userinfo string. Username is empty. 



1 0.2.5 IM sessions without destination preference for anonymity 

If the destination user did not state a preference for whether the session be anonymous, local policies and regulations 
may force the network operator to make it anonymous. The destination UE indicates its lack of preference by not 
providing a "privacy" tag on the Remote-Party-ID header. An example of this response from UE to P-CSCF (step#8 of 
MT#la, step#10 of MT#lb, step#8 of MT#2), is given in table 10.2.5-1. 

Table 10.2.5-1 : 183 Session Progress (UE to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK523r01 . 2 

Remote-Party-ID: "John Smith" <tel : +l-212-555-2222> 

RPID-Privacy : privacy=of f ; party=called 

From: 

To: tel:+l-212-555-2222; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 
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a=des:qos mandatory remote sendrecv 
a=conf:qos remote sendrecv' 
a=rtpmap:97 AMR 
a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 



Remote-Party-ID: 



Identifies the answering subscriber. It contains the public user identity, and the name of the 
answering party. The lack of a tag "privacy=" indicates lack of a preference for an 
anonymous or identified session. 



Based on local policy or regulatory requirements, the S-CSCF serving the originating subscriber may either allow the 
identification information to be given to the initiator (by following the example in subclause 10.2.6), or may restrict it 
(by following the example in subclause 10.2.4). 

1 0.3 Procedures for codec and media flow negotiations 

10.3.1 Introduction 

This subclause gives signalling flows for the procedures for determining the set of mutually-supported codecs between 
the endpoints of a multimedia session, determining the initial codecs to be used for the multimedia session, and the 
procedures for changing between codecs when multiple ones are supported. 

Editor's note; If transcoding is to be supported, these procedures need to be adjusted. 

1 0.3.2 Codec or media flow change within the existing reservation 

After the multimedia session is established, it is possible for either endpoint to change the set of media flows or codec 
for a media flow. If the change is within the resources akeady reserved, then it is only necessary to synchronise the 
change with the other endpoint. An admission control decision will not fail if the new resource request is within the 
existing reservation. 

As this flow may require user interaction at the remote end to accept the proposed changes, it is realized with a re- 
INVITE request. 

The signalling flow for changing a codec within an existing reservation is given in figure 10.3.2-1. 



Figure 10.3.2-1 : Codec or media flow change - same reservation 

For this example, we assume the session was established with authorization for two codecs, AMR and G726-32, but that 
AMR was initially chosen for the media. UE#1 now desires to change the media to use G726-32. 

The detailed procedure is as follows: 

1 . UE#1 stops sending media with old codec. 

UE#1 determines that a new media stream is desired, or that a change is needed in the codec in use for an 
existing media stream. UE#1 evaluates the impact of this change, and determines the existing resources 
reserved for the session are adequate. UE#1 builds a revised SDP that includes all the common media flows 
determined by the initial negotiation, but assigns a codec and port number only to those to be used onward. 
UE#1 stops transmitting media streams on those to be dropped from the session. 

2. INVITE (UE to P-CSCF) - see example in table 10.3.2-2 

UE#1 sends the INVITE request to P-CSCF#1 containing this SDP. 

Table 10.3.2-2: INVITE (UE to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Remote-Party-ID: "John Doe" <tel : +l-212-555-llll> 

RP ID -Privacy : privacy=of f ; party=calling 
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From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 INVITE 

Contact: sip: [5555: : aaa:bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 

m=video RTP/AVP 

m=audio 3456 RTP/AVP 96 

b=AS:25.4 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 



Request-URI: 

Via: 

From:/To:/Call-ID: 



Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Contains the IP address or FQDN of the originating UE. 

Contain the values previously used to establish the session, including the tag value from the 
response. 



Cseq: Next higher sequential value. 

Contact: The SIP URI that conatins the IP address or FQDN of the originating UE. 

SDP The SDP contains the revised set of codecs desired by UE#1 . 

3. INVITE (P-CSCF to S-CSCF) - see example in table 10.3.2-3 

P-CSCF#1 forwards the INVITE request to S-CSCF#1. 

Table 10.3.2-3: INVITE (P-CSCF to S-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
Remote-Party-ID : 
RPID-Privacy : 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
Record-Route : sip:pcscfl. homel .net; Ir 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



Route: Saved from the 200 (OK) response to the initial INVITE. 

4. INVITE (S-CSCF to S-CSCF) - see example in table 10.3.2-4 
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S-CSCF#1 forwards the INVITE request, through the S-CSCF to S-CSCF signalling flow procedures, to S- 
CSCF#2. 

Table 10.3.2-4: INVITE (S-CSCF to S-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Remote-Party-ID : 

RPID-Privacy : 

Route: sip: scscf 2 .home2 . net ; Ir, sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c = 

t = 



5. INVITE (S-CSCF to P-CSCF) - see example in table 10.3.2-5 

S-CSCF#3 forwards the INVITE request to P-CSCF#2. 

Table 10.3.2-5: INVITE (S-CSCF to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Remote-Party-ID : 

RPID-Privacy: 

Route: sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type : 

Content-Length : 



6. INVITE (P-CSCF to UE) - see example in table 10.3.2-6 

P-CSCF#2 forwards the INVITE request to UE#2. 
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Table 10.3.2-6: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .home2 . net;branch=z9hG4bK556g98 . 5 

Max-Forwards: 66 

Remote-Party-ID : 

RPID-Privacy : 

P-Media-Authorization: 0020000 100 100 10 170 64 66322e68 6f6d65322e6e6574000c020 133315331343363231 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type : 

Content-Length : 



Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.home2.net" with credentials "31S1462r'. 

7. UE#2 stops sending with old codec, and initializes receiver for new codec 

UE#2 receives the INVITE request, and agrees that it is a change within the previous resource reservation. 
UE#2 stops sending the media streams to be deleted, and initialises its media receivers for the new codec. 

UE#2 may optionally perform an alerting function at this point, and respond to UE#1 with a 180 Ringing 
provisional response (not shown in figure). When it is ready for the new media stream, UE#2 responds with a 
200 OK. 

8. 200 OK (UE to P-CSCF) - see example in table 10.3.2-8 

UE#2 responds to the INVITE request (6) with a 200 OK response, sent to P-CSCF#2. 

Table 10.3.2-8: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

Remote-Party-ID: "John Smith" <tel : +l-212-555-2222> 

RPID-Privacy : privacy=of f ; party=called 

From: 

To: 

Call-ID: 

CSeq: 131 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 

m=video RTP/AVP 

m=audio 6544 RTP/AVP 96 

b=AS:25.4 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 

9. 200 OK (P-CSCF to S-CSCF) - see example in table 10.3.2-9 
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P-CSCF#2 sends the 200 OK response to S-CSCF#2. 

Table 10.3.2-9: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Remote-Party-ID : 

RPID-Privacy : 

Record-Route: sip: scscf2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



10. 200 OK (S-CSCF to S-CSCF) - see example in table 10.3.2-10 

S-CSCF#2 sends the 200 OK response to S-CSCF#1. 

Table 10.3.2-10: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Remote-Party-ID: "John Smith" <tel : +l-212-555-2222> 

RPID-Privacy: 

Record-Route : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Type : 

Content-Length : 



1 1. 200 OK (S-CSCF to P-CSCF) - see example in table 10.3.2-11 

S-CSCF#1 sends the 200 OK response to P-CSCF#1. 

Table 10.3.2-11: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Remote-Party-ID : 

RPID-Privacy : 

Record-Route : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Type : 

Content-Length : 



12. 200 OK (P-CSCF to UE) - see example in table 10.3.2-12 

P-CSCF#1 sends the 200 OK response to UE#1. 

Table 10.3.2-12: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Remote-Party-ID : 

RPID-Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Type : 

Content-Length : 



P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

13. UE#1 starts sending with new codec, and initializes receiver for new codec 

UE#1 starts sending media using the new codecs. UE#1 also releases any excess resources no longer needed. 

14. ACK (UE to P-CSCF) - see example in table 10.3.2-14 

UE#1 sends the ACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.3.2-14: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
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Cseq: 131 ACK 

Contact: sip: [5555: : aaa:bbb: ccc: ddd] 

Content-Length: 



15. ACK (P-CSCF to S-CSCF) - see example in table 10.3.2-15 

P-CSCF#1 sends the ACK request to S-CSCF#1, along the signalHng path established by the INVITE 
request. 

Table 10.3.2-15: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

Route: Saved from the 200 OK response (with first element moved to Request-URI). 

16. ACK (S-CSCF to S-CSCF) - see example in table 10.3.2-16 

S-CSCF#1 sends the ACK request to S-CSCF#2, along the signalhng path established by the INVITE 
request. 

Table 10.3.2-16: ACK (S-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip : scscf 2 . home2 . net ; Ir, sip :pcscf 2 . visited2 . net ; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Length : 

17. ACK (S-CSCF to P-CSCF) - see example in table 10.3.2-17 

S-CSCF#2 sends the ACK request to P-CSCf#2, along the signalling path established by the INVITE request. 



Table 10.3.2-17: ACK (S-CSCF to P-CSCF) 



ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: @pcscf 2 . . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Length : 
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18. ACK (P-CSCF to UE) - see example in table 10.3.2-18 

P-CSCF#2 sends the ACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.3.2-18: ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

19. UE#2 starts sending with new codec 

UE#2 starts sending media using the new codecs. UE#2 also releases any excess resources no longer needed. 

1 0.3.3 Codec or media flow change requiring new resources and/or 
autinorisation 

After the multimedia session is established, it is possible for either endpoint to change the set of media flows or codec 
for a media flow. If the change requires additional resources beyond those previously reserved, then it is necessary to 
perform the resource reservation and bearer establishment procedures. If the reservation request fails for whatever 
reason, the original multimedia session remains in progress. 

An example signalling flow for a codec or media flow change requiring new resources and/or authorization is given in 
figure 10.3.3-1. This example shows mobile originated while in home network, establishing a session with another 
mobile served by the same network operator, also in its home network (M0#2, S-S#2, MT#2). Other configurations 
may include I-CSCFs in the signalling path; procedures at the I-CSCFs are identical to those described for the BYE, 
PRACK, and UPDATE requests and responses described in other clauses. 

As this flow may require user interaction at the remote end to accept the proposed changes, it is realized with a re- 
INVITE request. 
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UE#1 



1 . Determine new set of 
codecs for this session 



-2. INVITE - 



P-CSCF#1 S-CSCF#1 



3. Reduce set of codecs 
based on operator policy 



-4. INVITE - 



5. Reduce set of codecs 
based on operator policy 



-16. 183- 



1 7. Authorize change in 
resources for this session 



-18. 183- 



19. determine initial 
codec for this session 



30. reserve resources for 

new codec. If successful, 

stop sending with old codec 



-45. 180 Ringing - 
-46. PRACK - 
-55. 200 OK - 



-61.200OK- 



62. Start sending with new 

codec, setup receiver for 

new codec 



-63. ACK- 



-44. 180 Ringing - 
-47. PRACK - 
-54. 200 OK - 



-60. 200 OK- 



-64. ACK- 



-6. INVITE- 



S-CSCF#2 P-CSCF#2 



7. Reduce set of codecs 
based on operator policy 



15. 183 Session 
Progress 



-43. 180 Rlnging- 
-48. PRACK - 
-53. 200 OK - 



-59. 200 OK- 



-65 ACK- 



-8. INVITE - 



UE#2 



9. Reduce set of codecs 
based on operator policy 



-10. INVITE- 



1 1 . Determine subset of 

codecs supported by 

UE#2 



-12. 183- 



13. Authorize change in 
resources for this session 



14. 183 Session 
Progress 



-42. 180 Ringing - 
-49. PRACK - 
-52. 200 OK - - 



-58. 200 OK- 



-66. ACK- 



30. reserve resources for 
new codec 



-41. 180 Ringing- 

-50. PRACK - 

- -51. 200 OK - 



56. Stop sending with old 

codec, setup receiver for 
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-57. 200 OK- 



-67. ACK- 



68. Start sending with 
new codec 



Figure 10.3.3-1 : Codec or media flow change - new reservation 
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The detailed procedure is as follows: 

1 . Determine new set of codecs for this session 

UE#1 determines the revised set of codecs or media streams that it is wishes to support for this session. It 
builds a SDP containing bandwidth requirements and characteristics of each, and assigns local port numbers 
for each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in 
SDP), there may be multiple codec choices offered. 

For this example, assume UE#1 originally established the session using audio (AMR) only, and now wishes 
to change to stereo (using the L16 2-channel codec, RTP/AVP code 10) and add an additional video media 
stream (MPV). 

2. INVITE (UE to P-CSCF) - see example in table 10.3.3-2 

UE#1 sends the INVITE request to P-CSCF#1 containing this SDP. 

Table 10.3.3-2: INVITE (UE to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Remote-Party-ID: "John Doe" <tel : +l-212-555-llll> 

RPID-Privacy : privacy=of f ; party=calling 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel: +1-2 12-555-2222 ;tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc: ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 345 6 RTP/AVP 10 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

Request-URI: Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Via: Contains the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

Contact: The SIP URL that contains the IP address or FQDN of the originating UE. 

SDP The SDP contains the revised set of codecs desired by UE#1 . 

3. P-CSCF reduces set of supported codecs based on operator policy 

P-CSCF#1 examines the media parameters, and removes any choices that the network operator decides based 
on local policy, not to allow on the network. 
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4. INVITE (P-CSCF to S-CSCF) - see example in table 10.3.3-4 

P-CSCF#1 forwards the INVITE request to S-CSCF#1. 

Table 10.3.3-4: INVITE (P-CSCF to S-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ;branch=z9hG4bKnashds7 
Max-Forwards: 69 
Remote-Party-ID : 
RPID-Privacy : 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
Record-Route : sip:pcscfl. homel .net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 



Route: Saved from the 200 (OK) response to the initial INVITE. 

5. S-CSCF reduces set of supported codecs based on operator policy 

S-CSCF#1 examines the media parameters, and removes any choices that the subscriber does not have 
authority to request. 

6. INVITE (S-CSCF to S-CSCF) - see example in table 10.3.3-6 

S-CSCF#1 forwards the INVITE request, through the S-CSCF to S-CSCF signalling flow procedures, to S- 

CSCF#2. 

Table 10.3.3-6: INVITE (S-CSCF to S-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Remote-Party-ID : 

RPID-Privacy: 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip : scscf 1 . homel . net ; Ir, sip : pcscf 1 . homel . net ; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 
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Contact : 
Content-Type : 
Content-Length ; 



7. S-CSCF reduces set of supported codecs based on operator policy 

S-CSCF#2 examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. 

8. INVITE (S-CSCF to P-CSCF) - see example in table 10.3.3-8 

S-CSCF#3 forwards the INVITE request to P-CSCF#2. 

Table 10.3.3-8: INVITE (S-CSCF to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Remote-Party-ID : 

RPID-Privacy : 

Record-Route: sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

Route: sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



9. P-CSCF reduces set of supported codecs based on operator policy 
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P-CSCF#2 examines the media parameters, and removes any that the network operator decides, based on 
local policy, not to allow on the network. 

10. INVITE (P-CSCF to UE) - see example in table 10.3.3-10 

P-CSCF#2 forwards the INVITE request to UE#2. 

Table 10.3.3-10: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

Max-Forwards: && 

Remote-Party-ID : 

RPID-Privacy : 

P-Media-Authorization: 0020000100100101706466322e686f 6d65322e6e6574000c020133315331343363231 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.home2.net" with credentials "31S1462r'. 

1 1 . Determine set of codecs supported by UE#2 

UE#2 determines the set of codecs that it is capable of supporting for this session. 
For this example, assume UE#2 supports all those requested by UE#1. 
12. 183 Session Progress (UE to P-CSCF) - see example in table 10.3.3-12 

UE#2 returns a 183 Session Progress response, containing the SDP answer, to P-CSCF#2. 

Table 10.3.3-12: 183 Session Progress (UE to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

Require: lOOrel 

Remote-Party-ID: "John Smith" <tel : +l-212-555-2222> 

RPID-Privacy : privacy=of f ; party=called 

From: 

To: 

Call-ID: 
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CSeq: 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 18 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 



IN IP6 5555: 
:bbb 



o=- 2987933615 2987933615 

s=- 

c=IN IP6 5555: :eee:fff :aaa 

t=907165275 

m=video 6540 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 6544 RTP/AVP 10 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 



: eee : f f f : aaa : bbb 



SDP The SDP contains an answer to the received offer. 

13. Authorize resources for common codecs for this session 

P-CSCF#2 authorises the QoS resources for the common media flows and codec choices. 
14. 183 Session Progress (P-CSCF to S-CSCF) - see example in table 10.3.3-14 

P-CSCF#2 forwards the 183 Session Progress response to S-CSCF#2. 

Table 10.3.3-14: 183 Session Progress (P-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 . visited2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, 

sip:pcscfl .visitedl . net; Ir 

Require : 

Remote-Party-ID : 

RPID-Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 
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15. 183 Session Progress (S-CSCF to S-CSCF) - see example in table 10.3.3-15 

S-CSCF#2 forwards the 183 Session Progress response to S-CSCF#1. 

Table 10.3.3-15: 183 Session Progress (S-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

Require : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



16. 183 Session Progress (S-CSCF to P-CSCF) - see example in table 10.3.3-16 

S-CSCF#1 forwards the 183 Session Progress response to P-CSCF#1. 

Table 10.3.3-16: 183 Session Progress (S-CSCF to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
Require : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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17. Authorize resources for common codecs for this session 

P-CSCF#1 authorises the QoS resources for the remaining media flows and codec choices. 
18. 183 Session Progress (P-CSCF to UE) - see example in table 10.3.3-18 

P-CSCF#1 forwards the 183 Session Progress response to UE#1. 

Table 10.3.3-18: 183 Session Progress (P-CSCF to UE) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Media-Authorization: 002 00 100 100 10 170 64 663 12e68 6f6d65312e6e6574000c020 13 9425 63330373200 

Require : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdfl.homel.net" with credentials "9BV3072". 

19. Determine revised codec(s) for this session 

UE#1 determines which media flows should be used for this session, and which codecs should be used for 
each of those media flows. If there was any change in media flows, or if there was more than one choice of 
codec for a media flow, then UE#1 must include an SDP in the PRACK request sent to UE#2. 
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For this example, assume UE#1 chooses LIO for stereo audio and MPV for video, so no changes are made to 
the SDP. 

20. PRACK (UE to P-CSCF) - see example in table 10.3.3-20 

UE#1 sends the PRACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.3.3-20: PRACK (UE to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel: +1-212-555-2222; tag=314 159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 132 PRACK 

Rack: 18 131 INVITE 

Content-Length: 

Request-URI: Takes the value of the Contact header of the received 183 Session Progress response. 

From:/To:/Call-ID: Copied from the 183 Session Progress response so that they include any tag parameter. 
Cseq: Takes a higher value than that in the previous request. 

21. PRACK (P-CSCF to S-CSCF) - see example in table 10.3.3-21 

P-CSCF#1 sends the PRACK request to S-CSCF#1, along the signalling path estabUshed by the INVITE 
request. 

Table 10.3.3-21 : PRACK (P-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf2 .home2 . net; Ir, sip:pcscf2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

Route: Saved from the previous response. 

22. PRACK (S-CSCF to S-CSCF) - see example in table 10.3.3-22 

S-CSCF#1 sends the PRACK request to S-CSCF#2, along the signalling path estabUshed by the INVITE 
request. 

Table 10.3.3-22: PRACK (S-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .home2 . net; Ir, sip : pcscf 2 . home2 . net ; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

23. PRACK (S-CSCF to P-CSCF) - see example in table 10.3.3-23 
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S-CSCF#2 sends the PRACK request to P-CSCf#2, along the signalling path established by the INVITE 
request. 

Table 10.3.3-23: PRACK (S-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

24. PRACK (P-CSCF to UE) - see example in table 10.3.3-24 

P-CSCF#2 sends the PRACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.3.3-24: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

25. 200 OK (UE to P-CSCF) - see example in table 10.3.3-25 

UE#2 responds to the PRACK request (24) with a 200 OK response to P-CSCF#2. 

Table 10.3.3-25: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

via: SIP/2. 0/UDP pcscf 2 .home2 . net;branch=z9hG4bK876tl2 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

26. 200 OK (P-CSCF to S-CSCF) - see example in table 10.3.3-26 

P-CSCF#2 sends the 200 OK response to S-CSCF#2. 

Table 10.3.3-26: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 
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27. 200 OK (S-CSCF to S-CSCF) - see example in table 10.3.3-27 

S-CSCF#2 sends the 200 OK response to S-CSCF#1. 

Table 10.3.3-27: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

28. 200 OK (S-CSCF to P-CSCF) - see example in table 10.3.3-28 

S-CSCF#1 sends the 200 OK response to P-CSCF#1. 

Table 10.3.3-28: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

29. 200 OK (P-CSCF to UE) - see example in table 10.3.3-29 

P-CSCF#1 sends the 200 OK response to UE#1. 

Table 10.3.3-29: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

30. Reserve resources for new media streams 

UE#1 and UE#2 reserve the resources needed for the added or changed media flows. If the reservation is 
successfully completed by UE#1, it stops transmitting any deleted media streams. 

31. UPDATE (UE to P-CSCF) - see example in table 10.3.3-31 

UE#1 sends the UPDATE request to P-CSCF#1. 

Table 10.3.3-31 : UPDATE (UE to P-CSCF) 

UPDATE sip: [5555:eee:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel: +1-212-555-2222; tag=3 14 15 9 

Call-ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 133 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 
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t=907165275 

m=video 34 RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local sendrecv 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 345 6 RTP/AVP 10 

b=AS:25.4 

a=curr;qos local senedrecv 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 



CSeq: Takes a higher value than that in the previous request. 

The SDP indicates that the resource reservation was successful in the local segment. 
32. UPDATE (P-CSCF to S-CSCF) - see example in table 10.3.3-32 

P-CSCF#1 sends the UPDATE request to S-CSCF#1. 



Table 10.3.3-32: UPDATE (P-CSCF to S-CSCF) 



UPDATE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lel] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=l; pdp- 
sig=no; gcid=723084392; auth-token=43876648; flow-id=2 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



Route: Saved from the 183 Session Progress response . 

33. UPDATE (S-CSCF to S-CSCF) - see example in table 10.3.3-33 

S-CSCF#1 sends the UPDATE request to S-CSCF#2. 

Table 30.3.3-33: UPDATE (M0#2 to S-S) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf2 .home2 . net; Ir^ sip:pcscf2 .home2 . net; Ir 
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P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



34. UPDATE (S-CSCF to P-CSCF) - see example in table 10.3.3-34 

S-CSCF#2 sends the UPDATE request to P-CSCF#2. 

Table 10.3.3-34: UPDATE (S-CSCF to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



35. UPDATE (P-CSCF to UE) - see example in table 10.3.3-35 

P-CSCF#2 sends the UPDATE request to UE#2. 

Table 10.3.3-35: UPDATE (P-CSCF to UE) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP pcscf 2 .home2 . net;branch=z9hG4bK876tl2 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



v= 



Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

36. 200 OK (UE to P-CSCF) - see example in table 10.3.3-36 

UE#2 responds to the UPDATE request (35) with a 200 OK response, sent to P-CSCF#2. 

Table 10.3.3-36: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .home2 . net; branch=z9hG4bK876tl2 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : aaa :bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video 6540 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 6544 RTP/AVP 10 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

37. 200 OK (P-CSCF to S-CSCF) - see example in table 10.3.3-37 

P-CSCF#2 sends the 200 OK response to S-CSCF#2. 

Table 10.3.3-37: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 
SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length: (...) 



38. 200 OK (S-CSCF to S-CSCF) - see example in table 10.3.3-38 

S-CSCF#2 sends the 200 OK response to S-CSCF#1. 

Table 10.3.3-38: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



39. 200 OK (S-CSCF to P-CSCF) - see example in table 10.3.3-39 

S-CSCF#1 sends the 200 OK response to P-CSCF#1. 

Table 10.3.3-39: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
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Content-Type : 
Content-Length : 



40. 200 OK (P-CSCF to UE) - see example in table 10.3.3-40 

P-CSCF#1 sends the 200 OK response to UE#1. 

Table 10.3.3-40: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



41. 180 Ringing (UE to P-CSCF) - see example in table 10.3.3-41 

Depending on the type of codec change being performed, alerting may be required at the destination UE. If 
so, UE#2 sends a 180 Ringing provisional response to the originator, through P-CSCF#2. 

Table 10.3.3-41 : 180 Ringing (UE to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

From: 

To: 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 19 

Content-Length: 
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42. 180 Ringing (P-CSCF to S-CSCF) - see example in table 10.3.3-42 

P-CSCF#2 sends the 180 Ringing response to S-CSCF#2. 

Table 10.3.3-42: 180 Ringing (P-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2, home2 . net; Ir, sip : scscf 2 . home2 . net ; Ir, sip : scscf 1 . homel . net ; Ir, 

sip:pcscfl . homel .net; Ir 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 

ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=l; pdp- 

sig=no; gcid=309685786; auth-token=86243681; flow-id=2 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

43. 180 Ringing (S-CSCF to S-CSCF) - see example in table 10.3.3-43 

S-CSCF#2 sends the 180 Ringing response to S-CSCF#1. 

Table 10.3.3-43: 180 Ringing (S-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

44. 180 Ringing (S-CSCF to P-CSCF) - see example in table 10.3.3-44 

S-CSCF#1 sends the 180 Ringing response to P-CSCF#1. 

Table 10.3.3-44: 180 Ringing (S-CSCF to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

45. 180 Ringing (P-CSCF to UE) - see example in table 10.3.3-45 

P-CSCF#1 sends the 180 Ringing response to UE#1. 
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Table 10.3.3-45: 180 Ringing (P-CSCF to UE) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Require : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 

Editor's Note: Additional QoS interactions to handle one-way media at this point (e.g. for PSTN ringback and 
announcements) is for further study. 

46. PRACK (UE to P-CSCF) - see example in table 10.3.3-46 

UE#1 sends the PRACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.3.3-46: PRACK (UE to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel: +1-2 12-555-2222 ;tag=3 14 159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 PRACK 

Rack: 19 131 INVITE 

Content-Length: 

47. PRACK (P-CSCF to S-CSCF) - see example in table 10.3.3-47 

P-CSCF#1 sends the PRACK request to S-CSCF#1, along the signalling path estabUshed by the INVITE 
request. 

Table 10.3.3-47: PRACK (P-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scsfl .homel . net; Ir, sip: scscf2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

Route: P-CSCF adds a Route header, with the saved value from the previous response. 

48. PRACK (S-CSCF to S-CSCF) - see example in table 10.3.3-48 

S-CSCF#1 sends the PRACK request to S-CSCF#2, along the signalling path estabUshed by the INVITE 
request. 

Table 10.3.3-48: PRACK (S-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1. homel. net ;branch=z9hG4bK4 31h2 3.1, SIP /2. 0/UDP [5555: : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf2 .home2 .net; Ir, sip:pcscf2 .home2 .net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 
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Content-Length : 

49. PRACK (S-CSCF to P-CSCF) - see example in table 10.3.3-49 

S-CSCF#2 sends the PRACK request to P-CSCf#2, along the signalling path established by the INVITE 
request. 

Table 10.3.3-49: PRACK (S-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

50. PRACK (P-CSCF to UE) - see example in table 10.3.3-50 

P-CSCF#2 sends the PRACK request to UE#2, along the signalling path estabhshed by the INVITE request. 

Table 10.3.3-50: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: ^^ 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

51. 200 OK (UE to P-CSCF) - see example in table 10.3.3-51 

UE#2 responds to the PRACK request (50) with a 200 OK response to P-CSCF#2. 

Table 10.3.3-51 : 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .home2 . net; branch=z9hG4bK876tl2 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

52. 200 OK (P-CSCF to S-CSCF) - see example in table 10.3.3-52 

P-CSCF#2 sends the 200 OK response to S-CSCF#2. 

Table 10.3.3-52: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 
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Content-Length : 

53. 200 OK (S-CSCF to S-CSCF) - see example in table 10.3.3-53 

S-CSCF#2 sends the 200 OK response to S-CSCF#1. 

Table 10.3.3-53: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

54. 200 OK (S-CSCF to P-CSCF) - see example in table 10.3.3-54 

S-CSCF#1 sends the 200 OK response to P-CSCF#1. 

Table 10.3.3-54: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

55. 200 OK (P-CSCF to UE) - see example in table 10.3.3-55 

P-CSCF#1 sends the 200 OK response to UE#1. 

Table 10.3.3-55: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

56. Perform Codec change 

UE#2 stops sending the media streams to be deleted, and initiahses its media receivers for the new codec. 
57. 200 OK (UE to P-CSCF) - see example in table 10.3.3-57 

UE#2 responds to the INVITE request (10) with a 200 OK response, sent to P-CSCF#2. 

Table 10.3.3-57: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

From: 

To: 

Call-ID: 

CSeq: 131 INVITE 

Content-Length: 



58. 200 OK (P-CSCF to S-CSCF) - see example in table 10.3.3-58 
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P-CSCF#2 sends the 200 OK response to S-CSCF#2. 

Table 10.3.3-58: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir^ 

sip:pcscfl . homel .net; Ir 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 

ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=l; pdp- 

sig=no; gcid=309685786; auth-token=86243681; flow-id=2 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

59. 200 OK (S-CSCF to S-CSCF) - see example in table 10.3.3-59 

S-CSCF#2 sends the 200 OK response to S-CSCF#1. 

Table 10.3.3-59: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

60. 200 OK (S-CSCF to P-CSCF) - see example in table 10.3.3-60 

S-CSCF#1 sends the 200 OK response to P-CSCF#1. 

Table 10.3.3-60: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

61. 200 OK (P-CSCF to UE) - see example in table 10.3.3-61 

P-CSCF#1 sends the 200 OK response to UE#1. 

Table 10.3.3-61 : 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 
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P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

62. Start using new codec 

UE#1 starts sending media using the new codecs. UE#1 also releases any excess resources no longer needed. 

63. ACK (UE to P-CSCF) - see example in table 10.3.3-63 

UE#1 sends the ACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.3.3-63: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel : +1-2 12-555-2222, •tag=3 14 15 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 ACK 

Content-Length: 

64. ACK (P-CSCF to S-CSCF) - see example in table 10.3.3-64 

P-CSCF#1 sends the ACK request to S-CSCF#1, along the signalUng path established by the INVITE 
request. 

Table 10.3.3-64: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

65. ACK (S-CSCF to S-CSCF) - see example in table 10.3.3-65 

S-CSCF#1 sends the ACK request to S-CSCF#2, along the signalhng path established by the INVITE 
request. 

Table 10.3.3-65: ACK (S-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2home2 . net; Ir, sip:pcscf 2 .home2 . net 

Record-Route : sip:scscfl. homel .net 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

66. ACK (S-CSCF to P-CSCF) - see example in table 10.3.3-66 

S-CSCF#2 sends the ACK request to P-CSCf#2, along the signalling path established by the INVITE request. 

Table 10.3.3-66: ACK (S-CSCF to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

67. ACK (P-CSCF to UE) - see example in table 10.3.3-67 

P-CSCF#2 sends the ACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.3.3-67: ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

68. Start using new codec 

UE#2 starts sending media using the new codecs. UE#2 also releases any excess resources no longer needed. 

1 0.3.4 Error in changing codec or media flow witinin an existing reservation 

After the multimedia session is established, it is possible for either endpoint to change the set of media flows or codec 
for a media flow. If the change is within the resources already reserved, then it is only necessary to synchronise the 
change with the other endpoint. An admission control decision will not fail if the new resource request is within the 
existing reservation. 

However, it is possible the destination UE can no longer support the requested codec, due to, for example, other 
simultaneous sessions involving the destination UE. The destination UE therefore has the ability to refuse the codec 
change. 

The signalling flow for refusing a codec change within an existing reservation is given in figure 10.3.4-1. 
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UE#1 



1. stop sending media 
with old codec 



-2. INVITE - 



-16. 415Fail- 
— 17. ACK— 



18. Resume sending with 
previous codec 



P-CSCF#1 S-CSCF#1 



-3. INVITE- 



-14. 415Fail- 
— 15. ACK— 



-4. INVITE- 



-12. 415Fail- 
— 13. ACK— 



S-CSCF#2 P-CSCF#2 



-5. INVITE - 



-10. 415Fail- 
— 11. ACK- 



UE#2 



-6. INVITE- 



7. Attempt change to 
new codec 



-8. 415Fail- 
—9. ACK- 



Figure 1 0.3.4-1 : Error changing codec or media flow - within previous reservation 

For this example, we assume the session was estabHshed with authorization for two codecs, AMR and G726-32, but that 
AMR was initially chosen for the media. UE#1 now desires to change the media to use G726-32. 

The detailed procedure is as follows: 

1 . UE#1 stops sending media with old codec. 

UE#1 determines that a new media stream is desired, or that a change is needed in the codec in use for an 
existing media stream. UE#1 evaluates the impact of this change, and determines the existing resources 
reserved for the session are adequate. UE#1 builds a revised SDP that includes all the common media flows 
determined by the initial negotiation, but assigns a codec and port number only to those to be used onward. 
UE#1 stops transmitting media streams on those to be dropped from the session. 

2. INVITE (UE to P-CSCF) - see example in table 10.3.4-2 

UE#1 sends the INVITE request to P-CSCF#1 containing this SDP. 

Table 10.3.4-2: INVITE (UE to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Remote-Party-ID: "John Doe" <tel : -H-212-555-llll> 

RPID-Privacy : privacy=off; party=calling 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:-H-2 12-555-2222, •tag=314 159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 INVITE 

Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 



2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
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c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 

m=video RTP/AVP 

m=audio 345 6 RTP/AVP 96 

b=AS:25.4 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 



Request-URI: 

Via: 

From:/To:/Call-ID: 



Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Contains the IP address or FQDN of the originating UE. 

Contain the values previously used to establish the session, including the tag value from the 
response. 



Cseq: Next higher sequential value. 

Contact: It contains a SIP URL with the IP address or FQDN of the originating UE. 

SDP The SDP contains the revised set of codecs desired by UE#1 . 

3. INVITE (P-CSCF to S-CSCF) - see example in table 10.3.4-3 

P-CSCF#1 forwards the INVITE request to S-CSCF#1. 

Table 10.3.4-3: INVITE (P-CSCF to S-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
Remote-Party-ID : 
RPID-Privacy : 

Route: sip:pcscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
Record-Route : sip:pcscfl. homel .net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Content-Type : 
Content-Length : 



Route: Saved from the 200 (OK) response to the initial INVITE 

4. INVITE (S-CSCF to S-CSCF) - see example in table 10.3.4-4 

S-CSCF#1 forwards the INVITE request, through the S-CSCF to S-CSCF signalling flow procedures, to S- 
CSCF#2. 

Table 10.3.4-4: INVITE (S-CSCF to S-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Max-Forwards: 68 

Remote-Party-ID : 

RPID-Privacy : 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscf 1 .homel . net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



5. INVITE (S-CSCF to P-CSCF) - see example in table 10.3.4-5 

S-CSCF#3 forwards the INVITE request to P-CSCF#2. 

Table 10.3.4-5: INVITE (S-CSCF to P-CSCF) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Remote-Party-ID : 

RPID-Privacy: 

Record-Route: sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

Route: sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



6. INVITE (P-CSCF to UE) - see example in table 10.3.4-6 

P-CSCF#2 forwards the INVITE request to UE#2. 

Table 10.3.4-6: INVITE (P-CSCF to UE) 



INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .home2 .net;branch=z9hG4bK556g98 . 5 

Max-Forwards: 66 
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Remote-Party-ID : 

RPID-Privacy : 

P-Media-Authorization: 0020000 100 100 10 170 64 66322e68 6f6d65322e6e6574000c020 1333 1533 13433 63231 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.home2.net" with credentials "31S1462r'. 



7. UE#2 attempts to change to new codec 

UE#2 receives the INVITE request, and agrees that it is a change within the previous resource reservation. 
UE#2 encounters a failure attempting to change to the new codec, due to, e.g., internal resources that were 
available when the session was initiated but which are no longer available. 

8. 415 Unsupported Media Type (UE to P-CSCF) - see example in table 10.3.4-8 

UE#2 responds to the INVITE request (6) with a 415 Unsupported Media Type response, sent to P-CSCF#2. 

Table 10.3.4-8: 415 Unsupported Media Type (UE to P-CSCF) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP pcscf 2 .home2 . net; branch=z9hG4bK556g98 . 5 

From: 

To: 

Call-ID: 

CSeq: 131 INVITE 

Content-Length: 

9. ACK (P-CSCF to UE) - see example in table 10.3.4-9 

P-CSCF#2 acknowledges the error response by sending an ACK request to UE#2. 

Table 10.3.4-9: ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

10. 415 Unsupported Media Type (P-CSCF to S-CSCF) - see example in table 10.3.4-10 
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P-CSCF#2 sends the 415 Unsupported Media Type response to S-CSCF#2. 

Table 10.3.4-10: 415 Unsupported Media Type (P-CSCF to S-CSCF) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP scscf 2 . home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

1 1. ACK (S-CSCF to P-CSCF) - see example in table 10.3.4-11 

S-CSCF#2 acknowledges the error response by sending an ACK request to P-CSCf#2, along the signalling 
path established by the INVITE request. 

Table 10.3.4-11 : ACK (S-CSCF to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

12. 415 Unsupported Media Type (S-CSCF to S-CSCF) - see example in table 10.3.4-12 

S-CSCF#2 sends the 415 Unsupported Media Type response to S-CSCF#1. 

Table 10.3.4-12: 415 Unsupported Media Type (S-CSCF to S-CSCF) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

13. ACK (S-CSCF to S-CSCF) - see example in table 10.3.4-13 

S-CSCF#1 acknowledges the error response by sending an ACK request to S-CSCF#2. 

Table 10.3.4-13: ACK (S-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

14. 415 Unsupported Media Type (S-CSCF to P-CSCF) - see example in table 10.3.4-14 

S-CSCF#1 sends the 415 Unsupported Media Type response to P-CSCF#1. 

Table 10.3.4-14: 415 Unsupported Media Type (S-CSCF to P-CSCF) 

SIP/2.0 415 Unsupported Media Type 
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Via: SIP/2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

15. ACK (P-CSCF to S-CSCF) - see example in table 10.3.4-15 

P-CSCF#1 acknowledges the error response by sending an ACK request to S-CSCF#1. 

Table 10.3.4-15: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

16. 415 Unsupported Media Type (P-CSCF to UE) - see example in table 10.3.4-16 

P-CSCF#1 sends the 415 Unsupported Media Type response to UE#1. 

Table 10.3.4-16: 415 Unsupported Media Type (P-CSCF to UE) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

17. ACK (UE to P-CSCF) - see example in table 10.3.4-17 

UE#1 acknowledges the error response by sending an ACK request to P-CSCF#1. 

Table 10.3.4-17: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

18. UE#1 resumes sending with previous codec 

UE#1 resumes sending media using the previous codecs. 

1 0.3.5 Error changing codec or media flows requiring new resources and/or 
autlnorisation 

After the multimedia session is established, it is possible for either endpoint to change the set of media flows or codec 
for a media flow. If the change requires additional resources beyond those previously reserved, then it is necessary to 
perform the resource reservation and bearer establishment procedures. If the reservation request fails for whatever 
reason, the original multimedia session remains in progress. 

If the destination UE is unable, or unwilling, to change to the new set of codecs, it may return a 415 Unsupported Media 
Type error response. 
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If the P-CSCF and/or S-CSCF disallow a particular media flow or codec appearing in the SDP from the initiating UE, 
and it is the last codec in the last media flow, the CSCF returns a 415 Unsupported Media Type error response. 

An example signalling flow for an error changing codec or media flow requiring new resources and/or authorization is 
given in figure 10.3.5-1. This is the case where the UE rejects the codec change; rejection by a CSCF is a subset of this 
signalling flow. 

This example shows mobile originated while in home network, establishing a session with another mobile served by the 
same network operator, also in its home network (MO#2, S-S#2, MT#2). Other configurations may include I-CSCFs in 
the signalling path; procedures at the I-CSCFs are identical to those described for the BYE, PRACK, and UPDATE 
requests and responses described in other clauses. 



UE#1 



P-CSCF#1 



1 . Determine new set of 
codecs for this session 



-2. INVITE- 



S-CSCF#1 



3. Reduce set of codecs 
based on operator policy 



20.415 
-Unsupported- 
Media Type 
— 21. ACK — 



-4. INVITE- 



S-CSCF#2 



5. Reduce set of codecs 
based on operator policy 



18.415 
-Unsupported- 
Media Type 
— 19. ACK — 



-6. INVITE- 



P-CSCF#2 



7. Reduce set of codecs 
based on operator policy 



16.415 
-Unsupported- 
Media Type 
— 17 ACK 



-8. INVITE- 



UE#2 



9. Reduce set of codecs 
based on operator policy 



14.415 
-Unsupported- 
Media Type 
— 15. ACK — 



-10. INVITE- 



1 1 . Determine subset of 

codecs supported by 

UE#2 



12.415 
-Unsupported- 
Media Type 
— 13. ACK 



Figure 10.3.5-1 : Error changing Codec or media flows needing a new reservation 
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The detailed procedure is as follows: 

1 . Determine new set of codecs for this session 

UE#1 determines the revised set of codecs that it is wishes to support for this session. It builds a SDP 
containing bandwidth requirements and characteristics of each, and assigns local port numbers for each 
possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there 
may be multiple codec choices offered. 

For this example, assume UE#1 originally established the session using audio (AMR) only, and now wishes 
to change to stereo (using the L16 2-channel codec, RTP/AVP code 10) and add an additional video media 
stream (MPV). 

2. INVITE (UE to P-CSCF) - see example in table 10.3.5-2 

UE#1 sends the INVITE request to P-CSCF#1 containing this SDP. 

Table 10.3.5-2: INVITE (UE to P-CSCF) 

INVITE sip: [5555:eee:fff :aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Remote-Party-ID: "John Doe" <tel : +l-212-555-llll> 

RPID-Privacy : privacy=off; party=calling 

From: sip : userl_publicl@homel , net ; tag=171828 

To: tel: +1-2 12-555-2222 ;tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 INVITE 

Require: precondition 

Support ed:_10 Orel 

Contact: sip: [5555: : aaa: bbb: ccc: ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 345 6 RTP/AVP 10 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

Request-URI: Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Via: Contains the IP address or FQDN of the originating UE. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

Contact: A SIP URI that contains the IP address or FQDN of the originating UE. 

SDP The SDP contains the revised set of codecs desired by UE#1 . 

3. P-CSCF reduces set of supported codecs based on operator policy 

P-CSCF#1 examines the media parameters, and removes any choices that the network operator decides based 
on local policy, not to allow on the network. 
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4. INVITE (P-CSCF to S-CSCF) - see example in table 10.3.5-4 

P-CSCF#1 forwards the INVITE request to S-CSCF#1. 

Table 10.3.5-4: INVITE (P-CSCF to S-CSCF) 

INVITE sip: [5555:eee:fff :aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ;branch=z9hG4bKnashds7 
Max-Forwards: 69 
Remote-Party-ID : 
RPID-Privacy : 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
Record-Route : sip:pcscfl. homel .net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 



Route: Saved from the 200 (OK) response to the initial INVITE. 

5. S-CSCF reduces set of supported codecs based on operator policy 

S-CSCF#1 examines the media parameters, and removes any choices that the subscriber does not have 
authority to request. 

6. INVITE (S-CSCF to S-CSCF) - see example in table 10.3.5-6 

S-CSCF#1 forwards the INVITE request, through the S-CSCF to S-CSCF signalling flow procedures, to S- 

CSCF#2. 

Table 10.3.5-6: INVITE (S-CSCF to S-CSCF) 

INVITE sip: [5555:eee:fff :aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Remote-Party-ID : 

RPID-Privacy: 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip : scscf 1 . homel . net ; Ir, sip : pcscf Ihomel . net ; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type : 
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Content-Length : 



7. S-CSCF reduces set of supported codecs based on operator policy 

S-CSCF#2 examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. 

8. INVITE (S-CSCF to P-CSCF) - see example in table 10.3.5-8 

S-CSCF#3 forwards the INVITE request to P-CSCF#2. 

Table 10.3.5-8: INVITE (S-CSCF to P-CSCF) 

INVITE sip: [5555:eee:fff :aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Remote-Party-ID : 

RPID-Privacy : 

Route: sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



9. P-CSCF reduces set of supported codecs based on operator policy 
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P-CSCF#2 examines the media parameters, and removes any that the network operator decides, based on 
local policy, not to allow on the network. 

10. INVITE (P-CSCF to UE) - see example in table 10.3.5-10 

P-CSCF#2 forwards the INVITE request to UE#2. 

Table 10.3.5-10: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 

Max-Forwards: && 

Remote-Party-ID : 

RPID-Privacy : 

P-Media-Authorization: 0020000100100101706466322e686f 6d65322e6e6574000c020133315331343363231 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

Via: P-CSCF removes the Via headers. It inserts this as a branch value on its Via header. 

P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.home2.net" with credentials "31S1462r'. 

1 1 . Determine subset of codecs supported by UE#2 

UE#2 determines the subset of codecs that it is capable of supporting for this session. It determines the 
intersection of those it supports with those appearing in the SDP in the INVITE request. For each media flow 
that is not supported, UE#2 inserts a SDP entry for media (m= line) with port=0. For each media flow that is 
supported, UE#2 inserts a SDP entry with an assigned port and with the codecs in common with those in the 
SDP from UE#1. 

For this example, assume UE#2 does not supports any of those requested by UE#1. 

12. 415 Unsupported Media Type (UE to P-CSCF) - see example in table 10.3.5-12 

UE#2 responds to the INVITE request (10) with a 415 Unsupported Media Type response, sent to P- 
CSCF#2. 

Table 10.3.5-12: 415 Unsupported Media Type (UE to P-CSCF) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK556g98 . 5 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



13. ACK (P-CSCF to UE) - see example in table 10.3.5-13 

P-CSCF#2 responds to the 415 Unsupported Media Type error (12) by sending an ACK request to UE#2. 

Table 10.3.5-13: ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

14. 415 Unsupported Media Type (P-CSCF to S-CSCF) - see example in table 10.3.5-14 

P-CSCF#2 sends the 415 Unsupported Media Type response to S-CSCF#2. 

Table 10.3.5-14: 415 Unsupported Media Type (P-CSCF to S-CSCF) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

15. ACK (S-CSCF to P-CSCF) - see example in table 10.3.5-15 

S-CSCF#2 responds to the 415 Unsupported Media Type error by sending an ACK request to P-CSCf#2, 
along the signalling path established by the INVITE request. 



Table 10.3.5-15: ACK (S-CSCF to P-CSCF) 



ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



16. 415 Unsupported Media Type (S-CSCF to S-CSCF) - see example in table 10.3.5-16 

S-CSCF#2 sends the 415 Unsupported Media Type response to S-CSCF#1. 

Table 10.3.5-16: 415 Unsupported Media Type (S-CSCF to S-CSCF) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 
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17. ACK (S-CSCF to S-CSCF) - see example in table 10.3.5-17 

S-CSCF#1 acknowledges the error indication (16) by sending an ACK request to S-CSCF#2, along the 
signalling path established by the INVITE request. 

Table 10.3.5-17: ACK (S-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

18. 415 Unsupported Media Type (S-CSCF to P-CSCF) - see example in table 10.3.5-18 

S-CSCF#1 sends the 415 Unsupported Media Type response to P-CSCF#1. 

Table 10.3.5-18: 415 Unsupported Media Type (S-CSCF to P-CSCF) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

19. ACK (P-CSCF to S-CSCF) - see example in table 10.3.5-19 

P-CSCF#1 acknowledges the error response (18) by sending an ACK request to S-CSCF#1. 

Table 10.3.5-19: ACK (P-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

20. 415 Unsupported Media Type (P-CSCF to UE) - see example in table 10.3.5-16 

P-CSCF#1 sends the 415 Unsupported Media Type response to UE#1. 

Table 10.3.5-16: 415 Unsupported Media Type (P-CSCF to UE) 

SIP/2.0 415 Unsupported Media Type 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

21. ACK (UE to P-CSCF) - see example in table 10.3.5-21 

UE#1 acknowledges the error response by sending an ACK request to P-CSCF#1. 

Table 10.3.5-21 : ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



10.4 Session redirection procedures 

10.4.1 Introduction 

This subclause gives signalling flows for the procedures for performing session redirection. The decision to redirect a 
session to a different destination may be made for different reasons by a number of different functional elements, and at 
different points in the establishment of the session. 

Three cases of session redirection prior to bearer establishment are presented, and one case of session redirection after 
bearer establishment. 

These cases enable the typical services of "Session Forward Unconditional", "Session Forward Busy", "Session 
Forward Variable", "Selective Session Forwarding", and "Session Forward No Answer", though it is important to 
recognise that the implementation is significantly different from the counterparts in the CS domain. 

10.4.2 Session redirection initiated by S-CSCF to IM CN subsystem 
(M0#2, MT#2 assumed) 

One of the entities in a basic session that may initiate a redirection is the S-CSCF of the destination subscriber. The 
subscriber profile information obtained from the HSS by the 'Cx-pull' during registration may contain complex logic 
and triggers causing session redirection. S-CSCF#2 sends the SIP INVITE request to the I-CSCF for the new 
destination (I-CSCF#F in the figure), who forwards it to S-CSCF#F, who forwards it to the new destination. 

In cases when the destination subscriber is not currently registered in the IM CN subsystem, the I-CSCF may assign a 
temporary S-CSCF to perform the service control on behalf of the intended destination. This temporary S-CSCF takes 
the role of S-CSCF#2 in figure 10.4.2-1. 

The service implemented by figure 10.4.2-1 is typically "Session Forward Unconditional", "Session Forward Variable" 
or "Selective Session Forwarding". S-CSCF#2 may also make use of knowledge of current sessions in progress at the 
UE, and implement "Session Forwarding Busy" in this way. 

There are 9 distinct signalling flows for this session redirection, as follows: 

• Single network operator performing origination, forwarding, and termination. 

• One network operator performing origination and forwarding, separate network operator performing termination, 
with a THIG between to maintain configuration independence. 

• One network operator performing origination and forwarding, separate network operator performing termination, 
without a THIG between. 

• One network operator performing origination, second network operator performing forwarding and termination, 
with a THIG between to maintain configuration independence. 

• One network operator performing origination, second network operator performing forwarding and termination, 
without a THIG between. 

• One network operator performing origination, second network operator performing forwarding, and third 
network operator performing termination, without any THIGs between them. 

• One network operator performing origination, second network operator performing forwarding, and third 
network operator performing termination, with a THIG between first two to maintain configuration 
independence 
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• One network operator performing origination, second network operator performing forwarding, and third 
network operator performing termination, with a THIG between second and third to maintain configuration 
independence. 

• One network operator performing origination, second network operator performing forwarding, and third 
network operator performing termination, with a THIG between all three to maintain configuration 
independence. 

Further, it is possible that a session will be redirected multiple times, so the above list generalizes to include multiple 
forwarding elements. 

All of these Session-Redirection procedures can be combined with MO#la, MO#lb, or MO#2 for session origination, 
and with MT#la, MT#lb, or MT#2 for session termination. 

Only the first case is shown here, with a single network operator performing origination, forwarding, and termination. 
The additional cases can be derived from the procedures shown here and in S-S#la, and S-S#lb. 

This case is shown in the signalling flow in figure 10.4.2-1. 
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Figure 10.4.2-1 : Session redirection initiated by S-CSCF to IIV! CN subsystem 

The IM CN subsystem - Session Redirection Procedure is as follows: 
1 . INVITE (MO to S-CSCF) - see example in table 10.4.2-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 10.4.2-1 : INVITE (MO to S-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Record-Route ; sip:pcscfl. homel .net; Ir 
Route: sip ; scscfl . homel . net ; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: sip : userl_publicl@homel . net ; tag=171828 
To: tel:+l-212-555-2222 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 
Require: precondition 
Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 
Content-Type: application/sdp 
Content-Length: (...) 
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v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 00 RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=video 3402 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode"Set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

2. 100 Trying (S-CSCF to MO) - see example in table 10.4.2-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 10.4.2-2: 100 Trying (S-CSCF to MO) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

3. Evaluation of initial filter criterias 

S-CSCF#1 validates the servie profile of this subscriber and evaluates the intial filter criterias. For this 
example, assume no Application Server involvement. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 10.4.2-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since it is a destination served by the same network operator, S-CSCF#1 
forwards the INVITE request directly to I-CSCF in the same network. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. S-CSCF removes the stream by 
seting the port number for that stream to zero. 
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Table 10.4.2-4: INVITE (S-CSCF to l-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa:bbb: ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP-URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

5. 100 Trying (I-CSCF to S-CSCF) - see example in table 10.4.2-5 

I-CSCF responds to the INVITE request (4) by sending a 100 Trying provisional response to S-CSCF#1. 

Table 10.4.2-5: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 
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To: 

Call-ID: 

CSeq: 

Content-Length: 



6. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [11]. 

Table 7.3.2-6a provides the parameters in the SIP INVITE request (flow 4), which are sent to the HSS. 

Table 7.3.2-6b provides the parameters sent from the HSS that need to be mapped to SIP INVITE (flow 7) 
and sent to S-CSCF. 

7. INVITE (I-CSCF to S-CSCF) - see example in table 10.4.2-7 

I-CSCF forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 10.4.2-7: INVITE (I-CSCF to S-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip: scscfl .homel . net; Ir, sip:pcscfl .homel . net; Ir 

Route: sip: scscf 2 .homel . net; Ir 

P -As sorted- Identity: 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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NOTE 1 : The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalHng 
path once the session is estabhshed. 

8. 100 Trying (S-CSCF to I-CSCF) - see example in table 10.4.2-8 

S-CSCF#2 responds to the INVITE request (7) with a 100 Trying provisional response. 

Table 10.4.2-8: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

9. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. Based on 
some service-specific criterion, S-CSCF#2 decides to redirect this session attempt to a new IM CN subsystem 
destination, at the URL sip:H-l-212-555-3333@homel.net;user=phone. 

10. INVITE (S-CSCF to I-CSCF) - see example in table 10.4.2-10 

S-CSCF#2 performs an analysis of the destination address, and determines the new destination is served by 
the same network operator. S-CSCF#2 forwards the INVITE request directly to to I-CSCF#F (which may be 
different than I-CSCF#1 consulted earlier). 

Table 10.4.2-10: INVITE (S-CSCF to I-CSCF) 

INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP sip: scscf 2 .homel . net, SIP/2. 0/UDP icscf 2_s .homel . net;branch=z9hG4bK871yl2 . 1, 

SIP/ 2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 66 

Record-Route: sip : scscf 2 . homel . net ; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP -URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

11. 100 Trying (I-CSCF to S-CSCF) - see example in table 10.4.2-11 

I-CSCF responds to the INVITE request (10) by sending a 100 Trying provisional response to S-CSCF#1. 

Table 10.4.2-11: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

12. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [11]. 

Table 7.3.2-6a provides the parameters in the SIP INVITE request (flow 10), which are sent to the HSS. 

Table 7.3.2-6b provides the parameters sent from the HSS that need to be mapped to SIP INVITE (flow 13) 
and sent to S-CSCF. 

13. INVITE (I-CSCF to S-CSCF) - see example in table 10.4.2-13 

I-CSCF forwards the INVITE request to the S-CSCF (S-CSCF#F) that will handle the session termination. 

Table 10.4.2-13: INVITE (I-CSCF to S-CSCF) 

INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP icscff . homel . net ; branch=z9hG4bK87rr82 . 1, SIP/2. 0/UDP 

scscf2.homel.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK0 9a23 8 . 1, 
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SIP/2.0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2.0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards ; 65 

Record-Route; scscf 2 .homel . net; Ir, scscf 1 .homel . net; Ir, pcscf 1 .homel . net; Ir 

Route; sip; scscff. homel . net; Ir 

P -Asserted- Identity; 

Privacy ; 

P-Charging-Vector ; 

From; 

To; 

Call-ID; 

Cseq; 

Require ; 

Supported; 

Contact ; 

Content-Type ; 

Content-Length ; 



NOTE 2: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

14. 100 Trying (S-CSCF to I-CSCF) - see example in table 10.4.2-14 

S-CSCF#2 responds to the INVITE request with a 100 Trying provisional response. 

Table 10.4.2-14: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via; SIP/2. 0/UDP icscff.home.net, SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf2_s .homel . net; branch=z9hG4bK0 9a23 8 . 1, SIP/ 2 .0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To; 

Call-ID; 
CSeq; 
Content-Length; 
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15. Evaluation of initial filter criterias 

S-CSCF#F validates the service profile of this subscriber and evaluates the initial filter criterias. 

16. INVITE (S-CSCF to MT) - see example in table 10.4.2-16 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#F remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 

S-CSCF#F examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 

Table 10.4.2-16: INVITE (S-CSCF to MT) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf f .homel . net; branch=z9hG4bKyiir82 . 4, SIP/2. 0/UDP 

icscf f .homel . net; branch=z9hG4bK87rr82 .1, SIP/ 2 .0/UDP scscf 2 .homel . net ; branch=z9hG4bK7 64z87 . 1, 

SIP/ 2 .0/UDP icscf 2_s .homel . net ; branch=z9hG4bK0 9a238 .1, SIP/ 2 .0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 64 

Record-Route: sip: scscf f. home . net; Ir^ sip: scscf2 .home2 . net; Ir^ sip: scscf 1 .homel . net; Ir^ 

sip: pcscfl . homel .net; Ir 

Route: sip:pcscff .homel . net; Ir 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b= 

a= 

a= 

a= 

a= 

a= 

m=video RTP/AVP 99 

b= 

a= 

a= 

a= 

a= 

a= 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 
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a=fmtp:97 mode-set=0, 2, 5, 7; maxf rames=2 
a=rtpmap:96 G726-32/8000 

17. 100 Trying (MT to S-CSCF) - see example in table 10.4.2-17 

S-CSCF#2 receives a 100 Trying provisional response to the INVITE request, as specified by the termination 
procedures. 

Table 10.4.2-17: 100 Trying (MT to S-S#2) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf f .homel .net;branch=z9hG4bKyiir82 . 4, SIP/2. 0/UDP 

icscff .homel.net ;branch=z9hG4bK87rr 82. 1, SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK7 64z87 . 1, 

SIP/ 2 .0/UDP icscf2_s .homel . net;branch=z9hG4bK0 9a23 8 . 1, SIP/ 2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

18. 183 Session Progress (MT to S-CSCF) - see example in table 10.4.2-18 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response, as per the termination procedure. 

Table 10.4.2-18: 183 Session Progress (MT to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf f . homel . net ; branch=z9hG4bKyiir82 . 4, SIP/2. 0/UDP 

icscff .homel. net; branch=z9hG4bK87rr 82. 1, SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK7 64z87 . 1, 

SIP/ 2 .0/UDP icscf2„s .homel . net ; branch=z9hG4bK0 9a23 8 . 1, SIP/ 2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route: sip:pcscff .homel . net; Ir, sip: scscf f. homel . net; Ir, sip: scscf 2 .homel . net; Ir, 

sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir 

P-Asserted-Identity: "John Smith" <tel : +l-212-555-3333> 

Privacy: none 

P-Charging-Vector : 

From: 

To: tel:+l-212-555-2222; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Supported: update 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

19. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 10.4.2-19 
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S-CSCF#2 forwards the 183 Session Progress provisional response to I-CSCF. 

Table 10.4.2-19: 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf f . homel . net ;branch=z9hG4bK87rr82 . 1, SIP/2. 0/UDP 

scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP icscf 2_s . homel . net ; branch=z9hG4bK0 9a23 8 . 1, 

SIP/ 2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted-Identity: "John Smith" <tel : +l-212-555-3333> 

Privacy: none 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Supported: 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 



20. 183 Session Progress (I-CSCF to S-CSCF) - see example in table 10.4.2-20 

1-CSCF forwards the 183 Session Progress provisional response to S-CSCF#1. 

Table 10.4.2-20: 183 Session Progress (I-CSCF to S-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . homel . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK0 9a238 .1, SIP/2 .0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity: 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Supported: 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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21. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 10.4.2-21 

S-CSCF#2 forwards the 183 Session Progress provisional response to 1-CSCF. 

Table 10.4.2-21 : 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P -Asserted- Identity: 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Supported: 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



22. 183 Session Progress (I-CSCF to S-CSCF) - see example in table 10.4.2-22 

I-CSCF forwards the 183 Session Progress provisional response to S-CSCF#1. 

Table 10.4.2-22: 183 Session Progress (I-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 
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Require ; 
Supported: 
Contact : 
RSeq: 

Content-Type : 
Content-Length ; 



23. 183 Session Progress (S-CSCF to MO) - see example in table 10.4.2-23 

S-CSCF#1 forwards the 183 Session Progress to the originator, as per the originating procedure. 

Table 10.4.2-23: 183 Session Progress (S-CSCF to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Supported: 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



10.4.3 



Session redirection initiated by S-CSCF to CS-domain (S-S#2, 
MT#2 assumed) 



The S-CSCF in the scenario above may determine that the session is to be redirected to a CS-domain endpoint, or to the 
PSTN. It recognizes this situation by the redirected URL being a tel: URL. 
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For the simplest configuration (Mobile located in home service area (MO#2), initiating a session to a destination served 
by same network operator(S-S#2)), the handling of redirection to a tel: URL is shown in figure 10.4.3-1. Other cases, 
which include roaming, PSTN origination, destinations served by other network operators, and THIGs, are handled in a 
similar manner. 



UE#1 



P-CSCF#I 



-1. INVITE 

2.100 
Trying 



18.302 
Redirect 



19. ACK 



20. UE initiates call 
CS domain 



S-CSCF#I 



3. INVITE 

4. 1 00^ 
T rying 



l-CSCF 



5. Evaluation of Initial 
Filter Criterias 



16.302 
Redirect 



17. ACK 



-6. INVITE 
7.100 
Trying 



14.302 
Redirect 



15. ACK 



HSS 



s-cscF#;? 



. Cx: User location 
query / 

9. INVITE- 

10. 100 - 

Tiying 



121.302 
Redirect 

13. ACK 



11. Evaluation of Initial 
Filter criterias 



Figure 10.4.3-1 : Session redirection initiated by S-CSCF to CS-Domain 

Step-by-step processing is as follows: 

1. INVITE (UE to P-CSCF) - see example in table 10.4.3-1 

UE sends the INVITE request, containing an initial SDP, to the P-CSCF determined via the CSCF discovery 
mechanism. 

Table 10.4.3-1 : INVITE (UE to P-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Preferred-Identity : "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy; none 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa:bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 34 00 RTP/AVP 98 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 
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a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H261 

a=rtpmap: 99 MPV 

m=video 3402 RTP/AVP 98 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap:98 H261 

a=rtpmap: 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Request-URI: Contains the keyed number from the user. This is specified by the UE as sipxkeyed 

number>@homel.net. This is in accordance to standard IETF procedure for specifying 
dialled digits. 

Via: Contains the IP address or FQDN of the originating UE. 

P-Asserted-Identity: the user provides a hint about the identity to be used for this session. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause 'Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

From:/To:/Call-ID: Follow the recommendations of draft-ietf-sip-privacy [13], even though anonymity is not 
being requested for this session. 

Cseq: is a random starting number. 

Contact: is a SIP URL that contains the IP address or FQDN of the originating UE. 

2. 100 Trying (P-CSCF to UE) - see example in table 10.4.3-2 

P-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 10.4.3-2: 100 Trying (P-CSCF to UE) 

SIP/2.0 100 Trying 

via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. INVITE (P-CSCF to S-CSCF) - see example in table 10.4.3-3 

P-CSCF remembers (from the registration procedure) the request routing for this UE. This becomes a Route 
header in the request. This next hop is the S-CSCF within the home network. 

P-CSCF adds itself to the Record-Route header and Via header. 
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P-CSCF examines the media parameters, and removes any choices that the network operator decides based 
on local policy, not to allow on the network. For this example, assume the network operator disallows H261 
video encoding. 

The INVITE request is forwarded to the S-CSCF. 

Table 10.4.3-3: INVITE (P-CSCF to S-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Record-Route ; sip;pcscfl. homel .net; Ir 
Route; sip; scscfl .homel . net; Ir 

P-Asserted-Identity; "John Doe" <tel ; +l-212-555-llll> 

P-Access-Network-Info; 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy ; 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
From; 
To; 

Call-ID; 
Cseq; 
Require ; 
Supported; 
Contact ; 
Content-Type ; 
Content-Length ; 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;99 MPV 

m=video 3402 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap; 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

Route: Contains the elements from the Path header from Registration. 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

SDP: The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the video media streams no longer list codec 98 (H261). 
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4. 100 Trying (S-CSCF to P-CSCF) - see example in table 10.4.3-4 

S-CSCF responds to the INVITE request (3) with a 100 Trying provisional response. 

Table 10.4.3-4: 100 Trying (S-CSCF to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

5. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

6. INVITE (S-CSCF to I-CSCF) - see example in table 10.4.3-6 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. S-CSCF removes the stream by 
seting the port number for that stream to zero. 

S-CSCF forwards the INVITE request, as specified by the S-CSCF to S-CSCF procedures. 
Table 10.4.3-6: INVITE (S-CSCF to I-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Record-Route: sip: scscfl .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll>; 

Privacy: none 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:99 MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
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a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP-URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

7. 100 Trying (I-CSCF to S-CSCF) - see example in table 10.4.3-7 

S-CSCF receives a 100 Trying provisional response, as specified by the S-CSCF to S-CSCF procedures. 



Table 10.4.3-7: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [11]. 

Table 7.3.2-6a provides the parameters in the SIP INVITE request (flow 6), which are sent to the HSS. 

Table 7.3.2-6b provides the parameters sent from the HSS that need to be mapped to SIP INVITE (flow 9) 
and sent to S-CSCF. 

9. INVITE (I-CSCF to S-CSCF) - see example in table 10.4.3-9 

I-CSCF forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 10.4.3-9: INVITE (I-CSCF to S-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .homel . net; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

Route: sip: scscf 2 .homel . net; Ir 

P-Asserted- Identity: 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

10. 100 Trying (S-CSCF to I-CSCF) - see example in table 10.4.3-10 

S-CSCF#2 responds to the INVITE request with a 100 Trying provisional response. 

Table 10.4.3-10: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP Icscf 2_s . homel . net ; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

1 1 . Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. Based on 
some service-specific criterion, S-CSCF#2 decides to redirect this session attempt to a CS-domain endpoint, 
at the URLtel:H-l-212-555-3333. 

12. 302 Moved Temporarily (S-CSCF to I-CSCF) - see example in table 10.4.3-12 

S-CSCF#2 sends a 302 Moved Temporarily response to I-CSCF, containing the new destination. 

Table 10.4.3-12: 302 Moved Temporarily (S-CSCF to I-CSCF) 

SIP/2.0 302 Moved Temporarily 
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Via: SIP/2. 0/UDP icscf 2_s .homel .net;branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact: tel : +1-212-555-3333 

Content-Length: 

13. ACK (I-CSCF to S-CSCF) - see example in table 10.4.3-13 

I-CSCF acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to S- 
CSCF#2. 

Table 10.4.3-13: ACK (I-CSCF to S-CSCF) 

ACK sip:scscf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .homel . net; branch=z9hG4bK09a238 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

14. 302 Moved Temporarily (I-CSCF to S-CSCF) - see example in table 10.4.3-14 

1-CSCF sends a 302 Moved Temporarily response to S-CSCF#1, containing the new destination. 

Table 10.4.3-14: 302 Moved Temporarily (I-CSCF to S-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length: 

15. ACK (S-CSCF to I-CSCF) - see example in table 10.4.3-15 

S-CSCF#1 acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to I- 
CSCF. 

Table 10.4.3-15: ACK (S-CSCF to I-CSCF) 

ACK sip:icscf2_s. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

16. 302 Moved Temporarily (S-CSCF to P-CSCF) - see example in table 10.4.3-16 

S-CSCF#1 sends a 302 Moved Temporarily response to P-CSCF, containing the new destination. 

Table 10.4.3-16: 302 Moved Temporarily (S-CSCF to P-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
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CSeq: 
Contact : 

Content-Length: 



17. ACK (P-CSCF to S-CSCF) - see example in table 10.4.3-17 

P-CSCF acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to S- 
CSCF#1. 

Table 10.4.3-17: ACK (P-CSCF to S-CSCF) 

ACK sip:scscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

18. 302 Moved Temporarily (P-CSCF to UE) - see example in table 10.4.3-18 

P-CSCF sends a 302 Moved Temporarily response to UE, containing the new destination. 

Table 10.4.3-18: 302 Moved Temporarily (P-CSCF to UE) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length: 

19. ACK (UE to P-CSCF) - see example in table 10.4.3-19 

UE acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to P-CSCF. 

Table 10.4.3-19: ACK (UE to P-CSCF) 

ACK tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

20. UE initiates session in CS domain 

UE initiates a session to the new destination given in the Contact header, using mechanisms of the CS 
domain. 

1 0.4.4 Session redirection initiated by S-CSCF to general endpoint (S-S#2, 
MT#2 assumed) 

The S-CSCF in the scenario above may determine that the session is to be redirected to an endpoint outside the IP 
MultiMedia System and outside the CS-domain. Examples of these destinations include web pages, email addresses, 
etc. It recognizes this situation by the redirected URL being other than a sip: or tel: URL. 

For the simplest configuration (Mobile located in home service area (MO#2), initiating a session to a destination served 
by same network operator(S-S#2)), the handling of redirection to a general URL is shown in figure 10.4.4-1. Other 
cases, which include roaming, PSTN origination, destinations served by other network operators, and THlGs, are 
handled in a similar manner. 
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Figure 10.4.4-1 : Session redirection initiated by S-CSCF to general endpoint 

Step-by-step processing is as follows: 

1. INVITE (UE to P-CSCF) - see example in table 10.4.4-1 

UE sends the INVITE request, containing an initial SDP, to the P-CSCF determined via the CSCF discovery 
mechanism. 

Table 10.4.4-1 : INVITE (UE to P-CSCF) 

INVITE tel:-H-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Preferred-Identity : "John Doe" <tel : -H-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy; none 

From; sip ; userl_publicl@homel . net ; tag=171828 

To; tel;-H-212-555-2222 

Call- ID; Cb03a0s0 9a2sdfglkj4 90333 

Cseq; 127 INVITE 

Require; precondition 

Supported; lOOrel 

Contact; sip; [5555; ; aaa;bbb; ccc ; ddd] 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 34 RTP/AVP 98 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap;98 H261 

a=rtpmap: 99 MPV 

m=video 3402 RTP/AVP 98 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 
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a=rtpmap: 98 H261 

a=rtpmap: 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Request-URI: Contains the keyed number from the user. This is specified by the UE as sipxkeyed 

number>@ ho mel.net. This is in accordance to standard IETF procedure for specifying 
dialled digits. 

Via: Contains the IP address or FQDN of the originating UE. 

P-Asserted-Identity: the user provides a hint about the identity to be used for this session. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 



From:/To:/Call-ID: 



Follow the recommendations of draft-ietf-sip-privacy [13], even though anonymity is not 
being requested for this session. 



Cseq: is a random starting number. 

Contact: is a SIP URL that contains the IP address or FQDN of the originating UE. 

2. 100 Trying (P-CSCF to UE) - see example in table 10.4.4-2 

P-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 10.4.4-2: 100 Trying (P-CSCF to UE) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. INVITE (P-CSCF to S-CSCF) - see example in table 10.4,4-3 

P-CSCF remembers (from the registration procedure) the request routing for this UE. This becomes a Route 
header in the request. This next hop is the S-CSCF within the home network. 

P-CSCF adds itself to the Record-Route header and Via header. 

P-CSCF examines the media parameters, and removes any choices that the network operator decides based 
on local policy, not to allow on the network. For this example, assume the network operator disallows H261 
video encoding. 

The INVITE request is forwarded to the S-CSCF. 
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Table 10.4.4-3: INVITE (P-CSCF to S-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Record-Route ; sip;pcscfl. homel .net; Ir 
Route; sip; scscfl .homel . net; Ir 

P-Asserted-Identity; "John Doe" <tel ; +l-212-555-llll> 

P-Access-Network-Info; 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy ; 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
From; 
To; 

Call-ID; 
Cseq; 
Require ; 
Supported; 
Contact ; 
Content-Type ; 
Content-Length ; 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap;99 MPV 

m=video 34 02 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap; 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

Route: Contains the elements from the Path header from Registration. 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

SDP: The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the video media streams no longer list codec 98 (H261). 
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4. 100 Trying (S-CSCF to P-CSCF) - see example in table 10.4.4-4 

S-CSCF responds to the INVITE request (3) with a 100 Trying provisional response. 

Table 10.4.4-4: 100 Trying (S-CSCF to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

5. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

6. INVITE (S-CSCF to I-CSCF) - see example in table 10.4.4-6 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. S-CSCF removes the stream by 
seting the port number for that stream to zero. 

S-CSCF forwards the INVITE request, as specified by the S-CSCF to S-CSCF procedures. 
Table 10.4.4-6: INVITE (S-CSCF to I-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Record-Route: sip: scscfl .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll>; 

Privacy: none 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:99 MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
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a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Request-URI: In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a TEL- 
URL [5], it has to be translated to a globally routable SIP-URL before applying it as Request-URI 
of the outgoing INVITE request. For this address translation the S-CSCF shall use the services of 
an ENUM-DNS protocol according to RFC 2916 [6], or any other suitable translation database. 
Database aspects of ENUM are outside the scope of this specification. 

7. 100 Trying (I-CSCF to S-CSCF) - see example in table 10.4.4-7 

S-CSCF receives a 100 Trying provisional response, as specified by the S-CSCF to S-CSCF procedures. 



Table 10.4.4-7: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [11]. 

Table 7.3.2-6a provides the parameters in the SIP INVITE request (flow 6), which are sent to the HSS. 

Table 7.3.2-6b provides the parameters sent from the HSS that need to be mapped to SIP INVITE (flow 9) 
and sent to S-CSCF. 

9. INVITE (I-CSCF to S-CSCF) - see example in table 10.4.4-9 

I-CSCF forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 10.4.4-9: INVITE (I-CSCF to S-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .homel . net; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

Route: sip: scscf 2 .homel . net; Ir 

Supported: 

P-Asserted- Identity: 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

10. 100 Trying (S-CSCF to I-CSCF) - see example in table 10.4.4-10 

S-CSCF#2 responds to the INVITE request with a 100 Trying provisional response. 

Table 10.4.4-10: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s .homel .net;branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

1 1 . Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. Based on 
some service-specific criterion, S-CSCF#2 decides to redirect this session attempt to a PS-domain endpoint, 
at the URL mailto:alienblaster@home.net. 

12. 302 Moved Temporarily (S-CSCF to I-CSCF) - see example in table 10.4.4-12 

S-CSCF#2 sends a 302 Moved Temporarily response to I-CSCF, containing the new destination. 

Table 10.4.4-12: 302 Moved Temporarily (S-CSCF to I-CSCF) 

SIP/2.0 302 Moved Temporarily 
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Via: SIP/2. 0/UDP icscf 2_s .homel .net;branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : mailto : alienblasterShome . net 

Content-Length: 

13. ACK (I-CSCF to S-CSCF) - see example in table 10.4.4-13 

I-CSCF acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to S- 
CSCF#2. 

Table 10.4.4-13: ACK (I-CSCF to S-CSCF) 

ACK sip:scscf2. home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .homel . net; branch=z9hG4bK09a238 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

14. 302 Moved Temporarily (I-CSCF to S-CSCF) - see example in table 10.4.4-14 

1-CSCF sends a 302 Moved Temporarily response to S-CSCF#1, containing the new destination. 

Table 10.4.4-14: 302 Moved Temporarily (I-CSCF to S-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length: 

15. ACK (S-CSCF to I-CSCF) - see example in table 10.4.4-15 

S-CSCF#1 acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to I- 
CSCF. 

Table 10.4.4-15: ACK (S-CSCF to I-CSCF) 

ACK sip:icscf2_s. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

16. 302 Moved Temporarily (S-CSCF to P-CSCF) - see example in table 10.4.4-16 

S-CSCF#1 sends a 302 Moved Temporarily response to P-CSCF, containing the new destination. 

Table 10.4.4-16: 302 Moved Temporarily (S-CSCF to P-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
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CSeq: 
Contact : 

Content-Length: 



17. ACK (P-CSCF to S-CSCF) - see example in table 10.4.4-17 

P-CSCF acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to S- 
CSCF#1. 

Table 10.4.4-17: ACK (P-CSCF to S-CSCF) 

ACK sip:scscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

18. 302 Moved Temporarily (P-CSCF to UE) - see example in table 10.4.4-18 

P-CSCF sends a 302 Moved Temporarily response to UE, containing the new destination. 

Table 10.4.4-18: 302 Moved Temporarily (P-CSCF to UE) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length: 

19. ACK (UE to P-CSCF) - see example in table 10.4.4-19 

UE acknowledges receipt of the 302 Moved Temporarily response by sending an ACK request to P-CSCF. 

Table 10.4.4-19: ACK (UE to P-CSCF) 

ACK sip:pcscfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

20. UE initiates session in PS domain 

UE initiates a session to the new destination given in the Contact header, using mechanisms of the PS 
domain. 

1 0.4.5 Session redirection initiate(d by P-CSCF (S-S#2, MT#2 assumed) 

One of the entities in a basic session that may initiate a redirection is the P-CSCF of the destination subscriber. In 
handling of an incoming session setup attempt, the P-CSCF normally sends the INVITE request to the destination UE, 
and retransmits it as necessary until obtaining an acknowledgement indicating reception by the UE. 

In cases when the destination subscriber is not currently reachable in the IM CN subsystem (due to such factors as 
roaming outside the service area or loss of battery, but the registration has not yet expired), the P-CSCF may initiate a 
redirection of the session. The P-CSCF informs the S-CSCF of this redirection, without specifying the new location; S- 
CSCF determines the new destination and performs according to subclauses 10.4.2, 10.4.3, or 10.4.4, based on the type 
of destination. 
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This is shown in figure 10.4.5-1. 



S-CSCF#1 



— 1. INVITE — 
-2. lOOTrying- 



l-CSCF 



3. Evaluation of Initial 
Filter Criteria 



—4. INVITE — 
-5. tOOTrying- 



HSS 



-6. Location Query- 
— 7. Response - 



-8. INVITE— 
-9. lOOTrying- 



S-CSCF#2 P-CSCF#2 



10. Evaluation of Initial 
Filter Criteria 



— 11. INVITE — 
-12. 100 Trying- 



UE#2 



-13. INVITE- 



14. Timeout 



115. 480 Unavailable — 
16. ACK 



17. Evaluation of Initial 
Filter Criteria 



Figure 10.4.5-1: Session redirection initiated by P-CSCF 

Beginning with step #8, the step-by-step processing is as follows: 

8. INVITE (I-CSCF to S-CSCF) - see example in table 10.4.5-8 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 

Table 10.4.5-8: INVITE (I-CSCF to S-CSCF) 

INVITE tel:-H-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .homel . net; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip: scscfl .homel . net; Ir, sip:pcscfl .homel . net; Ir 

Route: sip: scscf 2 .homel . net; Ir 

P-Asserted-Identity: "John Doe" <tel : -H-212-555-llll>; 

Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:-H-212-555-2222 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require : 

Supported: 

Contact : 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:99 MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 
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a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



9. 100 Trying (S-CSCF to I-CSCF) - see example in table 10.4.5-9 

S-CSCF responds to the INVITE request (8) with a 100 Trying provisional response. 

Table 10.4.5-9: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

10. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

1 1. INVITE (S-CSCF to P-CSCF) - see example in table 10.4.5-11 

S-CSCF remembers (from the registration procedure) the UE Contact address and the next hop CSCF for this 
UE. It forwards the INVITE request to the P-CSCF. 

S-CSCF#F examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 



Table 10.4.5-11 : INVITE (S-CSCF to P-CSCF) 



INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK0 9a23 8 . 1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Record-Route: sip: scscf 2 .homel . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 
Route: sip:pcscfl .homel . net; Ir 
P -As sorted- Identity: 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
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Content-Type : 
Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Route: Built from the Path header stored at registration. 

Via:/Record-Route: S-CSCF adds itself. 



SDP: 



The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 
Unes for the second audio stream shows a port number zero, which removes it from the 
negotiation. 



12. 100 Trying (P-CSCF to S-CSCF) - see example in table 10.4.5-12 

P-CSCF responds to the INVITE request (11) with a 100 Trying provisional response. 

Table 10.4.5-12: 100 Trying (P-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . homel . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

13. INVITE (P-CSCF to UE) - see example in table 10.4.5-13 

P-CSCF examines the media parameters, and removes any that the network operator decides, based on local 
policy, not to allow on the network. 

For this example, assume the network operator does not allow 64 kb/s audio, so the PCMU codec is removed. 

P-CSCF removes the Record-Route and Via headers, calculates the proper Route header to add to future 
requests, and saves that information without passing it to UE. 

Table 10.4.5-13: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . homel . net ; branch=z9hG4bK523r01 . 2 

P-Media-Authorization: 0020000 100 100 10 170 64 663 12e68 6f6d65312e6e6574 000c020 13 9425 63330373200 

Max-Forwards : 65 

P -Asserted- Identity : 

Privacy : 
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From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v=0 



o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b= 



m=video RTP/AVP 99 

b= 

a= 



m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b= 

a= 

a= 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saves 
values. It inserts this as a branch value on its Via header. 



P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.homel.net" with credentials "31814621". 



SDP: 



The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 
lines for the first audio stream no longer contains codec "0" (PCMU), which removes it 
from the negotiation. 



14. Timeout 

P-CSCF never receives any response from UE#2, and assumes it is unreachable. 
15. 480 Temporarily Unavailable (P-CSCF to S-CSCF) - see example in table 10.4.5-15 

P-CSCF sends a 480 Temporarily Unavailable response to S-CSCF. 

Table 10.4.5-15: 480 Temporarily Unavailable (P-CSCF to S-CSCF) 

SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 
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Content-Length: 

16. ACK (S-CSCF to P-CSCF) - see example in table 10.4.5-16 

S-CSCF acknowledges receipt of the 480 Temporarily Unavailable response (15) by sending an ACK request 
to P-CSCF. 

Table 10.4.5-16: ACK (S-CSCF to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

17. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

S-CSCF#2 determines the proper redirection action to take for this session, based on the subscriber profile and 
network operator policy. 

If the session is being redirected to a sip URL, then the signalling flow continues with step #1 1 of 
subclause 10.4.2. 

If the session is being redirected to a tel URL, then the signalling flow continues with step #13 of 
subclause 10.4.3. 

If the session is being redirected to a general URL, then the signalling flow continues with step #13 of 
subclause 10.4.4. 

1 0.4.6 Session redirection initiated by UE (S-S#2, MT#2 assumed) 

The next entity in a basic session that may initiate a redirection is the UE of the destination subscriber. The UE may 
implement customer-specific feature processing, and base its decision to redirect this session on such things as identity 
of caller, current sessions in progress, other applications currently being accessed, etc. UE sends the SIP Redirect 
response to its P-CSCF, who forwards back along the signalling path to S-CSCF#1, who initiates a session to the new 
destination. 

The service implemented by this signalling flow is typically "Session Forward Busy", "Session Forward Variable" or 
"Selective Session Forwarding". 

This is shown in figure 10.4.6-1. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



423 



ETSI TS 124 228 V5.3.0 (2002-12) 



S-CSCF#1 



— 1. INVITE — 
-2. 100 Trying — 



l-CSCF 
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18. Evaluation of Initial 
Filter Criteria 



UE#2 



-13. INVITE- 



-14. Redirect - 
— 15. ACK— 



Figure 10.4.6-1 : Session redirection initiated by UE 

Beginning with step #8, the step-by-step processing is as follows: 

8. INVITE (I-CSCF to S-CSCF) - see example in table 10.4.6-8 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 

Table 10.4.6-8: INVITE (l-CSCF to S-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .homel .net;branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip: scscfl .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require : 

Supported: 

Contact : 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:99 MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 
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a=rtpmap: 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



9. 100 Trying (S-CSCF to I-CSCF) - see example in table 10.4.6-9 

S-CSCF responds to the INVITE request (8) with a 100 Trying provisional response. 

Table 10.4.6-9: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

10. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

1 1. INVITE (S-CSCF to P-CSCF) - see example in table 10.4.6-11 

S-CSCF remembers (from the registration procedure) the UE Contact address and the next hop CSCF for this 
UE. It forwards the INVITE request to the P-CSCF. 

S-CSCF#F examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 



Table 10.4.6-11 : INVITE (S-CSCF to P-CSCF) 



INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK492e09 . 1, SIP/2. 0/UDP 

icscf 2_s. homel. net ;branch=z9hG4bK0 9a23 8. 1, SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Record-Route: sip: scscf 2 .homel . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 
P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 

v=0 
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o==- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Route: Built from the Path header stored at registration. 

Via:/Record-Route: S-CSCF adds itself. 



SDP: 



The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 
lines for the second audio stream shows a port number zero, which removes it from the 
negotiation. 



12. 100 Trying (P-CSCF to S-CSCF) - see example in table 10.4.6-12 

P-CSCF responds to the INVITE request (11) with a 100 Trying provisional response. 

Table 10.4.6-12: 100 Trying (P-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK492e09 . 1, SIP/2. 0/UDP 

icscf2_s.homel.net;branch=z9hG4bK0 9a238. 1, S IP /2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b2 3 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

13. INVITE (P-CSCF to UE) - see example in table 10.4.6-13 

P-CSCF examines the media parameters, and removes any that the network operator decides, based on local 
policy, not to allow on the network. 

For this example, assume the network operator does not allow 64 kb/s audio, so the PCMU codec is removed. 

P-CSCF removes the Record-Route and Via headers, calculates the proper Route header to add to future 
requests, and saves that information without passing it to UE. 
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Table 10.4.6-13: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 .homel . net; branch=z9hG4bK39z58a. 1 

P-Media-Authorization: 020 0010010010170 64 66312e68 6f 6d65312e6e65740 0c02 013 9425 6333 03732 

Max-Forwards: 65 

P-Asserted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99 MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saves 

values. It inserts this as a branch value on its Via header. 

P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.homel.net" with credentials "31S1462r'. 

SDP: The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 

Unes for the first audio stream no longer contains codec "0" (PCMU), which removes it 
from the negotiation. 

14. 302 Moved Temporarily (UE to P-CSCF) - see example in table 10.4.6-14 

UE sends a 302 Moved Temporarily response to UE, specifying a new destination. 

Table 10.4.6-14: 302 Moved Temporarily (UE to P-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
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P-Preferred-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy; none 

From; 

To; 

Call-ID; 

CSeq; 

Contact; sip; +l-212-555-3333@homel .net; user=phone 

Content-Length; 

15. ACK (P-CSCF to UE) - see example in table 10.4.6-15 

S-CSCF acknowledges receipt of the 302 Moved Temporarily response (15) by sending an ACK request to 
P-CSCF. 

Table 10.4.6-15: ACK (P-CSCF to UE) 

ACK sip; [5555; ;eee;fff;aaa;bbb] SIP/2.0 

Via; SIP/2. 0/UDP pcscf 2 . homel . net ; branch=z9hG4bK39z58a . 1 

From; 

To; 

Call-ID; 

Cseq; 

Content-Length ; 

16. 302 Moved Temporarily (P-CSCF to S-CSCF) - see example in table 10.4.6-16 

P-CSCF sends a 302 Moved Temporarily response to S-CSCF, with the new destination. 

Table 10.4.6-16: 302 Moved Temporarily (P-CSCF to S-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via; SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK492e09 . 1, SIP/2. 0/UDP 

icscf2_s .homel . net; branch=z9hG4bK0 9a23 8 . 1, SIP/2 .0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 ; ; aaa:bbb: ccc ; ddd] ; branch=z9hG4bKnashds7 
P-Asserted-Identity; "John Smith" <tel ; +l-212-555-2222> 

P-Access-Network-Info; 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy ; 
From; 
To; 

Call-ID; 
CSeq; 
Contact ; 
Content-Length ; 

17. ACK (S-CSCF to P-CSCF) - see example in table 10.4.6-17 

S-CSCF acknowledges receipt of the 302 Moved Temporarily response (16) by sending an ACK request to 
P-CSCF. 

Table 10.4.6-17: ACK (S-CSCF to P-CSCF) 

ACK sip;pcscf2. homel. net SIP/2.0 

Via; SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK764z87 . 1 

From; 

To; 

Call-ID; 

Cseq; 

Content-Length ; 

18. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

S-CSCF#2 determines the proper redirection action to take for this session, based on the subscriber profile 
and network operator pohcy. 
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If the session is being redirected to a sip URL, then the signalling flow continues with step #1 1 of 
subclause 10.4.2. 

If the session is being redirected to a tel URL, then the signalling flow continues with step #13 of 
subclause 10.4.3. 

If the session is being redirected to a general URL, then the signalling flow continues with step #13 of 
subclause 10.4.4. 



10.4.7 Session redirection initiated after bearer establisliment 

The UE of the destination subscriber may request the session be redirected after a customer-specified ringing interval. 
The UE may also implement customer-specific feature processing, and base its decision to redirect this session on such 
things as the identity of caller, current sessions in progress, other applications currently being accessed, etc. The UE 
sends the SIP Redirect response to its P-CSCF, who forwards back along the signalling path to the originating endpoint, 
who initiates a session to the new destination. 

The service implemented by this signalling flow is typically "Session Forward No Answer". 

Redirection to another I CN subsystem endpoint (e.g. a sip: URL) is shown in figure 10.4.7-1. The figure starts at the 
point in the session establishment when the destination is known, resources have been reserved, and the destination 
subscriber is being alerted. If the desire for redirection was known earlier than this point, the procedures of Subclause 
10.4.6 would be followed instead. 
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Figure 10.4.7-1 : Session redirection after bearer establishment 
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Step-by-step processing is as follows: 

1 . 180 Ringing (UE to P-CSCF) - see example in table 10.4.7-1 

Depending on the type of codec change being performed, alerting may be required at the destination UE. If 
so, UE#2 sends a 180 Ringing provisional response to the originator, through P-CSCF#2. 

Table 10.4.7-1: 180 Ringing (UE to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 2 . homel . net ; branch=z9hG4bK556g98 . 5 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From; sip ; userl_publicl@homel . net ; tag=171828 

To: tel: +1-212-555-2222; tag=314 159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 INVITE 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 19 

Content-Length: 

2. 180 Ringing (P-CSCF to S-CSCF) - see example in table 10.4.7-2 

P-CSCF#2 sends the 180 Ringing response to S-CSCF#2. 

Table 10.4.7-2: 180 Ringing (P-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Record-Route: sip:pcscf 2 .homel . net : Ir, sip: scscf 2 .homel . net; Ir, sip: scscf 1 .homel . net; Ir^ 

sip:pcscfl . homel .net; Ir 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 

ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=l 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 

3. 180 Ringing (S-CSCF to S-CSCF) - see example in table 10.4.7-3 

S-CSCF#2 sends the 180 Ringing response to S-CSCF#1. 

Table 10.4.7-3: 180 Ringing (S-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 

4. 180 Ringing (S-CSCF to P-CSCF) - see example in table 10.4.7-4 

S-CSCF#1 sends the 180 Ringing response to P-CSCF#1. 

Table 10.4.7-4: 180 Ringing (S-CSCF to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 



5. 180 Ringing (P-CSCF to UE) - see example in table 10.4.7-5 

P-CSCF#1 sends the 180 Ringing response to UE#1. 

Table 10.4.7-5: 180 Ringing (P-CSCF to UE) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

RSeq: 

Content-Length : 

6. PRACK (UE to P-CSCF) - see example in table 10.4.7-6 

UE#1 sends the PRACK request to UE#2, along the signalling path established by the INVITE request. 

Table 10.4.7-6: PRACK (UE to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel: +1-2 12-555-2222, •tag=314 15 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 PRACK 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 

Raclt: 19 131 INVITE 

Content-Length: 



Request-URI: 



Takes the value of the Contact header of the 180 Ringing response. 



P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause ' Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

Via:, Contact: Take the value of either the IP address or FQDN of the UE. 

From:/To:/Call-ID: Copied from the 180 Ringing response so that they include any revised tag parameters. 

Cseq: Takes a higher value than in the previous request. 

7. PRACK (P-CSCF to S-CSCF) - see example in table 10.4.7-7 

P-CSCF#1 sends the PRACK request to S-CSCF#1, along the signalHng path estabUshed by the INVITE 
request. 

Table 10.4.7-7: PRACK (P-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .homel . net; Ir, sip:pcscf 2 .homel . net; Ir 
P-Access-Networlt-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
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To: 

Call-ID: 

Cseq: 

Contact : 
Rack: 
Content-Length : 



Route: 



P-CSCF adds a Route header, with the saved value from the previous response. 



P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

8. PRACK (S-CSCF to S-CSCF) - see example in table 10.4.7-8 

S-CSCF#1 sends the PRACK request to S-CSCF#2, along the signalling path estabhshed by the INVITE 
request. 

Table 10.4.7-8: PRACK (S-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Rack: 

Content-Length : 

9. PRACK (S-CSCF to P-CSCF) - see example in table 10.4.7-9 

S-CSCF#2 sends the PRACK request to P-CSCf#2, along the signalling path established by the INVITE 
request. 

Table 10.4.7-9: PRACK (S-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: 

SIP/ 2. 0/UDP scscf2.homel.net;branch=z9hG4bK7 64z87. 1, SIP/ 2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: pcscf 2 .homel . net; ir 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Rack: 

Content-Length : 

10. PRACK (P-CSCF to UE) - see example in table 10.4.7-10 

P-CSCF#2 sends the PRACK request to UE#2, along the signalling path estabhshed by the INVITE request. 

Table 10.4.7-10: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 .homel . net; branch=z9hG4bK526mj01 . 5 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Rack: 

Content-Length : 
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P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

11. 200 OK (UE to P-CSCF) - see example in table 10.4.7-11 

UE#2 responds to the PRACK request (10) with a 200 OK response to P-CSCF#2. 

Table 10.4.7-11: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . homel . net ; branch=z9hG4bK526m jOl . 5 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length: 

12. 200 OK (P-CSCF to S-CSCF) - see example in table 10.4.7-12 

P-CSCF#2 sends the 200 OK response to S-CSCF#2. 

Table 10.4.7-12: 200 OK (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP /2. 0/UDP [5555: : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

13. 200 OK (S-CSCF to S-CSCF) - see example in table 10.4.7-13 

S-CSCF#2 sends the 200 OK response to S-CSCF#1. 

Table 10.4.7-13: 200 OK (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

14. 200 OK (S-CSCF to P-CSCF) - see example in table 10.4.7-14 

S-CSCF#1 sends the 200 OK response to P-CSCF#1. 

Table 10.4.7-14: 200 OK (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 
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15. 200 OK (P-CSCF to UE) - see example in table 10.4.7-15 

P-CSCF#1 sends the 200 OK response to UE#1. 

Table 10.4.7-15: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. 

16. 302 Moved Temporarily (UE to P-CSCF) - see example in table 10.4.7-16 

Based on some service criterion, such as a timeout value, UE#2 decides to redirect this session request to 
another destination. UE#2 sends a 302 Moved Temporarily response to P-CSCF, containing the new 
destination. For this example, consider the new destination to be <sip:H-l-212-555- 
3333@home.net;user=phone>. 

Table 10.4.7-16: 302 Moved Temporarily (S-CSCF to l-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP pcscf 2 . homel . net ; branch=z9hG4bK523r01 . 2, SIP/2. 0/UDP 

scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP icscf2_s . homel . net ; branch=z9hG4bK0 9a23 8 . 1, 

SIP/ 2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact: tel : +1-212-555-3333 

Content-Length: 

17. ACK (P-CSCF to UE) - see example in table 10.4.7-17 

P-CSCF acknowledges receipt of the 302 Moved Temporarily response (16) by sending an ACK request to 

UE#2. 

Table 10.4.7-17: ACK (l-CSCF to S-CSCF) 

ACK sip:+l-212-555-2222@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .homel . net; branch=z9hG4bK523r01 . 2 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

18. Revoke QoS 

P-CSCF revokes any authorization is had made for Quality of Service for this session. 
19. 302 Moved Temporarily (P-CSCF to S-CSCF) - see example in table 10.4.7-19 

P-CSCF#2 sends a 302 Moved Temporarily response to S-CSCF#2, containing the new destination. 

Table 10.4.7-19: 302 Moved Temporarily (P-CSCF to S-CSCF) 

SIP/2.0 302 Moved Temporarily 
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Via: SIP/2. 0/UDP scscf 2 .homel .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK0 9a23 8 . 1, SIP/ 2 .0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

20. ACK (S-CSCF to P-CSCF) - see example in table 10.4.7-20 

S-CSCF acknowledges receipt of the 302 Moved Temporarily response (19) by sending an ACK request to 
P-CSCF#2. 

Table 10.4.7-20: ACK (S-CSCF to P-CSCF) 

ACK sip:pcscf2. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

21. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

If UE#2 has not subscribed to a session redirection service, then S-CSCF#2 may change the error response to 
a 480 Temporarily Unavailable. 

S-CSCF#2 generates a private URL containing the new destination, and places this new value as the Contact 
header in the response. Attempts to initiate a session to this destination shall be restricted to a short time 
period. 

22. 302 Moved Temporarily (S-CSCF to I-CSCF) - see example in table 10.4.7-22 

S-CSCF#2 sends a 302 Moved Temporarily response to I-CSCF, containing the updated destination. 

Table 10.4.7-22: 302 Moved Temporarily (S-CSCF to I-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact: sip: Token (tel: +1-2 12-555-3333 )@scscf2. homel .net; tokenized-by=scscf 2 . homel .net 

Content-Length : 

23. ACK (I-CSCF to S-CSCF) - see example in table 10.4.7-23 

I-CSCF acknowledges receipt of the 302 Moved Temporarily response (22) by sending an ACK request to S- 

CSCF#2. 



Table 10.4.7-23: ACK (I-CSCF to S-CSCF) 



ACK sip:scscf2. homel. net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .homel . net;branch=z9hG4bK09a238 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 
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24. 302 Moved Temporarily (I-CSCF to S-CSCF) - see example in table 10.4.7-24 

I-CSCF may (based on operator preferences) update the new destination address, in order to hide the S-CSCF 
address and maintain configuration independence. If so, it generates a new private URL with its own 
hostname. I-CSCF sends a 302 Moved Temporarily response to S-CSCF#1, containing the new destination. 

Table 10.4.7-24: 302 Moved Temporarily (I-CSCF to S-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact: sip: Token (token (tel: +1-2 12-555-3333 )@scscf2. homel .net; tokenized- 

by=scscf2 . homel . net ) @icscf 2_s . homel .net; tokenized-by=icscf 2__s . homel .net 

Content-Length: 

25. ACK (S-CSCF to I-CSCF) - see example in table 10.4.7-25 

S-CSCF#1 acknowledges receipt of the 302 Moved Temporarily response (24) by sending an ACK request to 
I-CSCF. 

Table 10.4.7-25: ACK (S-CSCF to I-CSCF) 

ACK sip:icscf2_s. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

26. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 
27. 302 Moved Temporarily (S-CSCF to P-CSCF) - see example in table 10.4.7-27 

S-CSCF#1 sends a 302 Moved Temporarily response to P-CSCF, containing the new destination. 

Table 10.4.7-27: 302 Moved Temporarily (S-CSCF to P-CSCF) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length: 

28. ACK (P-CSCF to S-CSCF) - see example in table 10.4.7-28 

P-CSCF acknowledges receipt of the 302 Moved Temporarily response (27) by sending an ACK request to 
S-CSCF#1. 

Table 10.4.7-28: ACK (P-CSCF to S-CSCF) 

ACK sip:scscfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 
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29. 302 Moved Temporarily (P-CSCF to UE) - see example in table 10.4.7-29 

P-CSCF sends a 302 Moved Temporarily response to UE, containing the new destination. 

Table 10.4.7-29: 302 Moved Temporarily (P-CSCF to UE) 

SIP/2.0 302 Moved Temporarily 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length: 

30. ACK (UE to P-CSCF) - see example in table 10.4.7-30 

UE acknowledges receipt of the 302 Moved Temporarily response (29) by sending an ACK request to P- 
CSCF. 

Table 10.4.7-30: ACK (UE to P-CSCF) 

ACK sip:pcscfl. homel.net SIP/2.0 

via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

31. INVITE (UE to P-CSCF) - see example in table 10.4.7-31 

UE sends the INVITE request, containing an initial SDP and the new destination, to the P-CSCF determined 
via the CSCF discovery mechanism. 

Table 10.4.7-31 : INVITE (UE to P-CSCF) 

INVITE sip: Token (token (tel:+l-212-555-3333) @scscf 2 . homel . net ; tokenized- 

by=scscf 2 . homel . net ) @icscf 2_s . homel .net; tokenized-by=icscf 2_s . homel .net SIP/2. 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Preferred-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 
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Request-URI: Contains the SIP URL from the Contact header in the received 302 Moved Temporarily 

message. 

Via: Contains the IP address or FQDN of the originating UE. 

P-Asserted-Identity: the user provides a hint about the identity to be used for this session. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause 'Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

From:/To:/Call-ID: Follow the recommendations of draft-ietf-sip-privacy[13], even though anonymity is not 
being requested for this session. 

Cseq: is a random starting number. 

Contact: is a SIP URL that contains the IP address or FQDN of the originating UE. 

32. 100 Trying (P-CSCF to UE) - see example in table 10.4.7-32 

P-CSCF responds to the INVITE request (31) with a 100 Trying provisional response. 

Table 10.4.7-32: 100 Trying (P-CSCF to UE) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

33. INVITE (P-CSCF to S-CSCF) - see example in table 10.4.7-33 

P-CSCF remembers (from the registration procedure) the request routing for this UE. This becomes a Route 
header in the request. This next hop is the S-CSCF within the home network. 

P-CSCF adds itself to the Record-Route header, and adds a Via header. 

The INVITE request is forwarded to the S-CSCF. 

Table 10.4.7-33: INVITE (P-CSCF to S-CSCF) 

INVITE sip: Token (token (tel:+l-2 12-555-3333) @scscf 2 .homel . net; tokenized- 
by=scscf2 . homel . net ) @icscf 2_s . homel .net; tokenized-by=icscf 2_s . homel .net SIP/2. 
Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Record-Route : sip:pcscfl. homel .net; Ir 
Route: sip: scscfl .homel . net; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy : 

P-Charging-Vector : icid-value=1234bcd987ba; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 

Require: precondition 
Supported: lOOrel 
Contact : 
Content-Type : 
Content-Length : 
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Route: 



Contains the elements from the Path header from registration. 



P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

SDP: The set of media flows described by the SDP may be reduced based on operator policy, or due to 

lack of authority of the subscriber to request such a media flow. Procedures are described in 
subclause 10.3.5. 

34. 100 Trying (S-CSCF to P-CSCF) - see example in table 10.4.7-34 

S-CSCF responds to the INVITE request (33) with a 100 Trying provisional response. 

Table 10.4.7-34: 100 Trying (S-CSCF to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

35. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

36. INVITE (S-CSCF to I-CSCF) - see example in table 10.4.7-36 

S-CSCF forwards the INVITE request to the I-CSCF specified in the destination URL. 

Table 10.4.7-36: INVITE (S-CSCF to I-CSCF) 

INVITE sip: Token (token (tel:+l-212-555-3333) @scscf 2 . homel . net ; tokenized- 

by=scscf2 . homel . net ) @icscf 2_s . homel .net; tokenized-by=icscf 2_s . homel .net SIP/2. 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Record-Route: sip: scscfl .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P -Asserted- Identity: 

Privacy: none 

P-Charging-Vector : icid-value=1234bcd987ba; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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Request-URI: This is the private URL obtained from the previous 302 Moved Temporarily response, which 

identifies the I-CSCF that must first translate the destination (then the S-CSCF that must further 
translate the destination). 

SDP: The set of media fiows described by the SDP may be reduced based on operator policy, or due to 

lack of authority of the subscriber to request such a media flow. Procedures are described in 
subclause 10.3.1. 

37. 100 Trying (I-CSCF to S-CSCF) - see example in table 10.4.7-37 

I-CSCF responds to the INVITE request (36) with a 100 Trying provisional response. 

Table 10.4.7-37: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

38. INVITE (I-CSCF to S-CSCF) - see example in table 10.4.7-38 

I-CSCF translates the private portion of the URL, and determines the destination is S-CSCF2. I-CSCF 
forwards the INVITE request to the S-CSCF#2 that will further translate the destination. 

Table 10.4.7-38: INVITE (I-CSCF to S-CSCF) 

INVITE sip:Token (tel:+l-212-555-3333) @scscf2. homel. net; tokenized-by=scscf 2 . homel . net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .homel .net;branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : icid-value=1234bcd987ba; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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39. 100 Trying (S-CSCF to I-CSCF) - see example in table 10.4.7-39 

S-CSCF#2 responds to the INVITE request (38) with a 100 Trying provisional response. 

Table 10.4.7-39: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2„s . homel . net ;branch=z9hG4bK09a238 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

40. INVITE (S-CSCF to I-CSCF) - see example in table 10.4.7-40 

S-CSCF translates the private portion of the URL, and determines the destination address. S-CSCF forwards 
the INVITE request to the I-CSCF#F, the entry point to the destination operator's network. 

Table 10.4.7-40: INVITE (S-CSCF to I-CSCF) 

INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s .homel . net; branch=z9hG4bK0 9a23 8 . 1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Record-Route: sip : scscf 2 . homel . net ; Ir, sip : scscf 1 . homel . net ; Ir^ sip :pcscfl . homel . net ; Ir 
P -As sorted- Identity : 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 



41. 100 Trying (I-CSCF to S-CSCF) - see example in table 10.4.7-41 

I-CSCF#F responds to the INVITE request (40) with a 100 Trying provisional response. 

Table 10.4.7-41 : 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . homel . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s .homel . net; branch=z9hG4bK0 9a23 8 . 1, SIP/ 2 .0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
Call-ID: 
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CSeq: 

Content-Length: 



The remainder of this session completes as shown in clause 8. 

10.5 Session transfer procedures 

10.5.1 Introduction 

This subclause gives signalling flows for the procedures for performing session transfers, subclause 10.5.2 gives the 
procedures for a transfer that initiates a new session (i.e. to a new destination not previously involved in the session) 
while the transferor and the transferee do not remain in the same network, subclause 10.5.3 gives the procedures for a 
transfer that replaces an existing session (i.e. to a destination that was previously involved in the session) while the 
transferor and the transferee remain in the same network. 

1 0.5.2 Session Transfer initiating a new session 

An IM session already exists between UE#1 and UE#2. UE#2 desires UE#1 to initiate a new session to a new 
destination, UE#3, and terminate the existing session. The procedures for this transfer are shown in figure 10.5.2-1. 
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Figure 10.5.2-1 : Session Transfer initiating a new session 
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1 . Session in Progress 

UE#1 initiates a multimedia session with UE#2. As a result, the state information stored at P-CSCF#2 is 
shown in table 10.5.2-1. 

Table 10.5.2-1 : State Information 



■ Request-URI: tel : +1-212-555-2222 




1 From; sip ; userl_publicl@homel . net ; tag=171828 




I To: tel:+l-212-555-2222;tag=314159 




i Call-ID: Cb03a0s09a2sdfglkj490333 




: CSeq(2dest): 127 INVITE 




j CSeq(2orig) : none 




1 Route: sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, 


sip:pcscfl .homel . net; Ir 


I Contact (orig) : sip: [5555 :: aaa:bbb: ccc : ddd] 





2. REFER (UE to P-CSCF) - see example in table 10.5.2-2 

UE#2 sends a Refer request to its proxy, P-CSCF#2. 

Table 10.5.2-2: REFER (UE to P-CSCF) 

REFER sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : eee : f f f : aaa:bbb] ; branch=z9hG4bK834y72 . 2 

Max-Forwards: 70 

P-Preferred-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: tel : +1-212-555-2222; tag=3 14 15 9 

To : sip : userl_publicl@homel . net; tag=17 1828 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 REFER 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

Refer-To: tel : +1-212-555-3333 

Content-Length: 

Request-URI: Contains the value of the Contact header from the initial INVITE. 

Via: Contains the IP address or FQDN of the originating UE. 

Privacy: the user does not require privacy, therefore the Privacy header is set to the value "none" as 

specified in draft-ietf-sip-asserted-identity [17] and draft-ietf-sip-privacy-general [13]. 

P-Asserted-Identity: the user provides a hint about the identity to be used for this session. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause 'Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

Froni:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

Contact: is a SIP URL that contains the IP address or FQDN of the originating UE. 

3. REFER (P-CSCF to S-CSCF) - see example in table 10.5.2-3 

P-CSCF adds a Route header, with the saved value corresponding to the session. 
P-CSCF#2 forwards the Refer request to S-CSCF#2. 

Table 10.5.2-3: REFER (P-CSCF to S-CSCF) 

REFER sip: [5555: :aaa:bbb:ccc:dddl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 .home2 . net; branch=z9hG4bK876tl2 . 1, SIP/2. 0/UDP 
[5555: :eee:fff :aaa:bbb] ; branch=z9hG4bK834y72 . 2 
Max-Forwards: 69 
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Route: sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscf 1 .homel . net; Ir 

P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy : 

P-Charging-Vector : icid-value=1234bcd94321; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Refer-To: 

Content-Length : 

Route: Saved from the 200 (OK) response to the initial INVITE. 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Contact: Contains a SIP URL with the IP address or FQDN of the UE. 

4. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

5. REFER (S-CSCF to S-CSCF) - see example in table 10.5.2-5 

In order to maintain the expectation of privacy of the identity of the new destination, S-CSCF#2 converts the 
"Refer-To" header into a private URL. S-CSCF#2 forwards the Refer request to S-CSCF#L 

Table 10.5.2-5: REFER (S-CSCF to S-CSCF) 

REFER sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

pcscf2.home2.net;branch=z9hG4bK87 6tl2. 1, SIP/ 2. 0/UDP [5555: : eee : f f f : aaa : bbb] ; branch=z9hG4bK834y72 . 2 

Max-Forwards: 68 

Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P -As sorted- Identity: 

Privacy: none 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Refer- To : sip: token (tel: +1-2 12-555-3333 )@scscf2. home 2 .net; tokenized-by=scscf2. home 2 .net 

Content-Length : 

6. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

7. REFER (S-CSCF to P-CSCF) - see example in table 10.5.2-7 

S-CSCF#1 forwards the Refer request to P-CSCF#L 

Table 10.5.2-7: REFER (S-CSCF to P-CSCF) 

REFER sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

scscf2.home2.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK87 6t 12 . 1, 

SIP/ 2. 0/UDP [5555: : eee : f f f : aaa :bbb] ;branch=z9hG4bK834y72 . 2 

Max-Forwards : 67 

Route: sip:pcscfl .homel . net; Ir 

P -As sorted- Identity: 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 
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Refer-To: 
Content-Length : 



8. REFER (P-CSCF to UE) - see example in table 10.5.2-8 

P-CSCF#1 forwards the Refer request to UE#1. 

Table 10.5.2-8: REFER (P-CSCF to UE) 

REFER sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK876tl2 . 1 

Max-Forwards: 66 

P -Asserted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Refer-To: 

Content-Length : 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 
values. It inserts this as a branch value on its Via header. 



9. 202-Accepted (UE to P-CSCF) - see example in table 10.5.2-9 

UE#2 acknowledges receipt of the Refer request (8) with a 202-Accepted final response, sent to P-CSCF#1. 

Table 10.5.2-9: 202 (Accepted) (UE to P-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK876t 12 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

10. 202-Accepted (P-CSCF to S-CSCF) - see example in table 10.5.2-10 

P-CSCF#1 forwards the 202 (Accepted) final response to S-CSCF#1. 

Table 10.5.2-10: 202 (Accepted) (P-CSCF to S-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

scscf2 .home2 . net; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP pcscf 2 .home2 . net ; branch=z9hG4bK87 6t 12 . 1, 

SIP /2. 0/UDP [5555: : eee : f f f : aaa : bbb] ; branch=z9hG4bK834y72 . 2 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

P-CSCF restores the Via headers from the branch value in its Via. 
1 1. 202-Accepted (S-CSCF to S-CSCF) - see example in table 10.5.2-11 

S-CSCF#1 forwards the 202 (Accepted) final response to S-CSCF#2. 

Table 10.5.2-11 : 202 (Accepted) (S-CSCF to S-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

pcscf2.home2.net;branch=z9hG4bK87 6tl2. 1, SIP/2. 0/UDP [5555: : eee : f f f : aaa : bbb] ; branch=z9hG4bK834y72 . 2 

From: 

To: 
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Call-ID: 
CSeq: 
Content-Length : 



12. 202-Accepted (S-CSCF to P-CSCF) - see example in table 10.5.2-12 

S-CSCF#2 forwards the 202 (Accepted) final response to P-CSCF#2. 

Table 10.5.2-12: 202 (Accepted) (S-CSCF to P-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1, SIP/2. 0/UDP 
[5555: :eee:fff :aaa:bbb] ; branch=z9hG4bK834y72 . 2 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

13. 202-Accepted (P-CSCF to UE) - see example in table 10.5.2-13 

P-CSCF#2 forwards the 202 (Accepted) final response to UE#2. 

Table 10.5.2-13: 202 (Accepted) (P-CSCF to UE) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP [5555 : : eee : f f f : aaa:bbb] ; branch=z9hG4bK834y72 . 2 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

14. NOTIFY (UE to P-CSCF) - see example in table 10.5.2-14 

UE#1 sends an immediate NOTIFY request to its proxy, P-CSCF#1. 

Table 10.5.2-14: NOTIFY (UE to P-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel: +1-212-555-2222; tag=3 14 15 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 NOTIFY 

Event : refer 

Content-Type: message/sipf rag 

Content-Length: (...) 

SIP/2.0 100 Trying 



Request-URI: 
Via: 



Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 
Contains the IP address or FQDN of the originating UE. 



P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause 'Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

15. NOTIFY (P-CSCF to S-CSCF) - see example in table 10.5.2-15 
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P-CSCF adds a Route header, with the saved value corresponding to the session. 
P-CSCF#1 forwards the NOTIFY request to S-CSCF#1. 

Table 10.5.2-15: NOTIFY (P-CSCF to S-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Event : 

Content-Type : 
Content-Length : 

SIP/2.0 100 Trying 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Route: Saved from the 200 (OK) response to the initial INVITE. 

16. NOTIFY (S-CSCF to S-CSCF) - see example in table 10.5.2-16 

S-CSCF#1 forwards the NOTIFY request to S-CSCF#2. 

Table 10.5.2-16: NOTIFY (S-CSCF to S-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Event : 

Content-Type : 

Content-Length : 

SIP/2.0 100 Trying 

17. NOTIFY (S-CSCF to P-CSCF) - see example in table 10.5.2-17 

S-CSCF#2 forwards the NOTIFY request to P-CSCF#2. 

Table 10.5.2-17: NOTIFY (S-CSCF to P-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Event : 

Content-Type : 

Content-Length : 

SIP/2.0 100 Trying 
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18. NOTIFY (P-CSCF to UE) - see example in table 10.5.2-18 

P-CSCF#2 forwards the NOTIFY request to UE#2. 

Table 10.5.2-18: NOTIFY (P-CSCF to UE) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Event : 

Content-Type : 

Content-Length : 

SIP/2.0 100 Trying 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

19. 200 (OK) (UE to P-CSCF) - see example in table 10.5.2-19 

UE#2 acknowledges receipt of the NOTIFY request (39) with a 200 (OK) final response, sent to P-CSCF#2. 

Table 10.5.2-19: 200 (OK) (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 .home2 . net; branch=z9hG4bK876tl2 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

20. 200 (OK) (P-CSCF to S-CSCF) - see example in table 10.5.2-20 

P-CSCF#2 forwards the 200 (OK) final response to S-CSCF#2. 

Table 10.5.2-20: 200 (OK) (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

P-CSCF restores the Via headers from the branch value in its Via. 
21. 200 (OK) (S-CSCF to S-CSCF) - see example in table 10.5.2-21 

S-CSCF#2 forwards the 200 (OK) final response to S-CSCF#1. 

Table 10.5.2-21 : 200 (OK) (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 
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Content-Length : 

22. 200 (OK) (S-CSCF to P-CSCF) - see example in table 10.5.2-22 

S-CSCF#1 forwards the 200 (OK) final response to P-CSCF#1. 

Table 10.5.2-22: 200 (OK) (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

23. 200 (OK) (P-CSCF to UE) - see example in table 10.5.2-23 

P-CSCF#1 forwards the 200 (OK) final response to UE#1. 

Table 10.5.2-23: 200 (OK) (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

24. INVITE (UE to P-CSCF) - see example in table 10.5.2-24 

UE#1 initiates an INVITE request based on the Refer-To header URL in the REFER request. The INVITE is 
sent from the UE to P-CSCF#1. 

Table 10.5.2-24: INVITE (UE to P-CSCF) 

INVITE sip:token (tel:+l-212-555-3333) @scscf2. home2.net; tokenized-by=scscf2 .home2 . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Frwards: 70 

P-Preferred-Identity : "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: sip : userl_publicl@homel .net;tag=171828 

To: tel:+l-212-555-2222 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc: ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 
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25. 100 (Trying) (P-CSCF to UE) - see example in table 10.5.2-25 

P-CSCF#1 responds to the INVITE request (24) with a 100 (Trying) provisional response. 

Table 10.5.2-25: 100 (Trying) (P-CSCF to UE) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length: 

26. INVITE (P-CSCF to S-CSCF) - see example in table 10.5.2-26 

P-CSCF#1 remembers (from the registration procedure) the request routing for this UE. This becomes a 
Route header in the request. 

P-CSCF adds itself to the Record-Route header and Via header. 

Table 10.5.2-26: INVITE (P-CSCF to S-CSCF) 

INVITE sip: token (tel:+l-2 12-555-3333) gscscf 2 . home2 . net ; tokenized-by=scscf 2 . home2 . net SIP/2.0 
Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Record-Route : sip:pcscfl. homel .net; Ir 
Route: sip: scscfl .homel . net; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 



27. 100 (Trying) (S-CSCF to P-CSCF) - see example in table 10.5.2-27 

S-CSCF#1 responds to the INVITE request (26) with a 100 (Trying) provisional response. 

Table 10.5.2-27: 100 (Trying) (S-CSCF to P-CSCF) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 
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28. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

29. INVITE (S-CSCF to I-CSCF) - see example in table 10.5.2-29 

S-CSCF#1 performs an analysis of the destination address, which is a private URL generated by S-CSCF#2. 
S-CSCF#1 determines the network operator to whom the destination subscriber belongs. Since (for this 
example) the forwarding network operator does not desire to keep their internal configuration hidden, S- 
CSCF#1 forwards the INVITE request directly to I-CSCF#2. 

Table 10.5.2-29: INVITE (S-CSCF to I-CSCF) 

INVITE sip:token (tel:+I-2I2-555-3333) @scscf2. home2.net; tokenized-by=scscf 2 .home2 . net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Asserted- Identity : 

Privacy: none 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



30. INVITE (I-CSCF to S-CSCF) - see example in table 10.5.2-30 

I-CSCF#2 performs an analysis of the destination address, which is a private URL generated by S-CSCF#2. 
I-CSCF#2 forwards the INVITE request directly to S-CSCF#2. 

Table 10.5.2-30: INVITE (I-CSCF to S-CSCF) 

INVITE sip:token (tel:+l-212-555-3333) @scscf2. home2.net; tokenized-by=scscf 2 .home2 . net SIP/2.0 

via: SIP/2. 0/UDP sip : icscf 2_s . home2 . net ; branch=z9hG4bK221s21 . 2, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip : scscf 1 . homel . net ; Ir, sip : pcscf 1 . homel . net ; Ir 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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NOTE 1 : The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the 

signalHng path once the session is established. 

31. 100 (Trying) (S-CSCF to I-CSCF) - see example in table 10.5.2-31 

I-CSCF#2 responds to the INVITE request (29) by sending a 100 (Trying) provisional response to S- 
CSCF#1. 

Table 10.5.2-31 : 100 (Trying) (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

32. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

33. INVITE (S-CSCF to I-CSCF) - see example in table 10.5.2-33 

S-CSCF#2 determines the destination address from the private URL contained in the INVITE request. Based 
on information in that URL, and information saved from step #4 above (implementation decision), S- 
CSCF#2 verifies the validity of the transfer request, and that it is within a short time delay from the REFER 
request. 

S-CSCF#2 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since (for this example) the forwarding network operator does not desire to 
keep their internal configuration hidden, S-CSCF#2 forwards the INVITE request directly to I-CSCF#3. 

Table 10.5.2-33: INVITE (S-CSCF to I-CSCF) 

INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/ 2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b2 3 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Record-Route: sip : scscf 2 . home2 . net ; Ir, sip : scscf 1 . homel . net ; Ir^ sip:pcscfl .homel . net; Ir 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
Privacy: none 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
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Content-Length : 



34. 100 (Trying) (I-CSCF to S-CSCF) - see example in table 10.5.2-34 

I-CSCF#3 responds to the INVITE request (33) by sending a 100 (Trying) provisional response to S- 

CSCF#2. 

Table 10.5.2-34: 100 (Trying) (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

35. Location Query 

I-CSCF (at the border of the terminating subscriber's network) queries the HSS for current location 
information. It will send "Cx-location-query" to the HSS to obtain the location information for the 
destination. 

36. Location Response 

HSS responds with the address of the current S-CSCF for the terminating subscriber. 

37. INVITE (I-CSCF to S-CSCF) - see example in table 10.5.2-37 

I-CSCF#3 forwards the INVITE request to the S-CSCF (S-CSCF#3) that will handle the session termination. 

Table 10.5.2-37: INVITE (I-CSCF to S-CSCF) 

INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP icscf 3_s .home3 . net; branch=z9hG4bK83thl2 . 7, SIP/2. 0/UDP 

scscf 2 .home2 . net; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, 

SIP/ 2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 65 

Route: sip: scscf 3 .home3 . net; Ir 

Record-Route: sip: scscf2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscf 1 .homel . net; Ir 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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NOTE 2: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalHng 
path once the session is established. 

38. 100 (Trying) (S-CSCF to I-CSCF) - see example in table 10.5.2-38 

S-CSCF#3 responds to the INVITE request (37) with a 100 (Trying) provisional response. 

Table 10.5.2-38: 100 (Trying) (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 3„s . homeS . net ;branch=z9hG4bK83thl2 . 7, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, 

SIP/ 2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

39. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criterias. 

40. INVITE (S-CSCF to P-CSCF) - see example in table 10.5.2-40 

S-CSCF#3 remembers (from the registration procedure) the next hop CSCF for this UE. It forwards the 
INVITE request to P-CSCF#3. 

Table 10.5.2-40: INVITE (S-CSCF to P-CSCF) 

INVITE sip: [5555: :aaa:bbb:ccc:fff] SIP/2.0 

Via: SIP/2. 0/UDP scscf 3 . home3 . nett ; branch=z9hG4bKe3yhlk . v, SIP/2. 0/UDP 

icscf 3„s .home3 . net; branch=z9hG4bK83thl2 .7, SIP/2 .0/UDP scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 . 1, 

SIP/2. 0/UDP icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1, SIP/ 2. 0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 64 

Route: sip:pcscf 3 .home3 . net; Ir 

Record-Route: sip: scscf 3 .home3 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir^ 

sip:pcscfl . homel .net; Ir 

P -Asserted- Identity: 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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41. 100 (Trying) (P-CSCF to S-CSCF) - see example in table 10.5.2-41 

P-CSCF#3 responds to the INVITE request (40) by sending a 100 (Trying) provisional response to S- 
CSCF#3. 

Table 10.5.2-41 : 100 (Trying) (P-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 3 . home3 . nett ; branch=z9hG4bKe3yhlk . v, SIP/2. 0/UDP 

icscf 3„s .home3 . net; branch=z9hG4bK83thl2 .7, SIP/ 2 .0/UDP scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 . 1, 

SIP/ 2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



42. INVITE (P-CSCF to UE) - see example in table 10.5.2-42 

P-CSCF forwards the INVITE request to the UE. 

Table 10.5.2-42: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :aaa:bbb:ccc:fffl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 3 .home3 . net;branch=z9hG4bK523r01 . 2 

Max-Forwards : 63 

P -Asserted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 



43. 100 (Trying) (UE to P-CSCF) - see example in table 10.5.2-43 

UE#3 may optionally send a 100 (Trying) provisional response to P-CSCF. 
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Table 10.5.2-43: 100 (Trying) (UE to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 3 .home3 . net;branch=z9hG4bK523r01 . 2 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

44. Completion of Session Initiation 

UE#1 and UE#3 complete the session initiation, as shown in the MO, S-S, and MT procedures. 

45. NOTIFY (UE to P-CSCF) - see example in table 10.5.2-45 

When the session with UE#3 has been successfully established, UE#1 sends a NOTIFY request to its proxy, 
P-CSCF#1. 

Table 10.5.2-45: NOTIFY (UE to P-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To: tel: +1-212-555-2222; tag=3 14 15 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 NOTIFY 

Event : refer 

Content-Type: message/sipf rag 

Content-Length: (...) 

SIP/2.0 200 OK 

Request-URI: Contains the value of the Contact header from the 200 (OK) response to the initial INVITE. 

Via: Contains the IP address or FQDN of the originating UE. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause 'Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. 

Cseq: Next higher sequential value. 

46. NOTIFY (P-CSCF to S-CSCF) - see example in table 10.5.2-46 

P-CSCF adds a Route header, with the saved value corresponding to the session. 
P-CSCF#1 forwards the NOTIFY request to S-CSCF#1. 

Table 10.5.2-46: NOTIFY (P-CSCF to S-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : icid-value=1234bc63957f ; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 
Event : 

Content-Type : 
Content-Length : 
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SIP/2.0 200 OK 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Route: Saved from the 200 (OK) response to the initial INVITE. 

47. NOTIFY (S-CSCF to S-CSCF) - see example in table 10.5.2-47 

S-CSCF#1 forwards the NOTIFY request to S-CSCF#2. 

Table 10.5.2-47: NOTIFY (S-CSCF to S-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf2 .home2 . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Event : 

Content-Type : 

Content-Length : 

SIP/2.0 200 OK 

48. NOTIFY (S-CSCF to P-CSCF) - see example in table 10.5.2-48 

S-CSCF#2 forwards the NOTIFY request to P-CSCF#2. 

Table 10.5.2-48: NOTIFY (S-CSCF to P-CSCF) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip:pcscf 2 .home2 . net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Event : 

Content-Type : 

Content-Length : 

SIP/2.0 200 OK 

49. NOTIFY (P-CSCF to UE) - see example in table 10.5.2-49 

P-CSCF#2 forwards the NOTIFY request to UE#2. 

Table 10.5.2-49: NOTIFY (P-CSCF to UE) 

NOTIFY sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

Max-Forwards: 66 

From: 

To: 

Call-ID: 

Cseq: 

Event : 

Content-Type : 

Content-Length : 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 459 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

SIP/2.0 200 OK 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

50. 200 (OK) (UE to P-CSCF) - see example in table 10.5.2-50 

UE#2 acknowledges receipt of the NOTIFY request (49) with a 200 (OK) final response, sent to P-CSCF#2. 

Table 10.5.2-50: 200 (OK) (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length: 

51. 200 (OK) (P-CSCF to S-CSCF) - see example in table 10.5.2-51 

P-CSCF#2 forwards the 200 (OK) final response to S-CSCF#2. 

Table 10.5.2-51 : 200 (OK) (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .home 1 . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

P-CSCF restores the Via headers from the branch value in its Via. 
52. 200 (OK) (S-CSCF to S-CSCF) - see example in table 10.5.2-52 

S-CSCF#2 forwards the 200 (OK) final response to S-CSCF#1. 

Table 10.5.2-52: 200 (OK) (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

53. 200 (OK) (S-CSCF to P-CSCF) - see example in table 10.5.2-53 

S-CSCF#1 forwards the 200 (OK) final response to P-CSCF#1. 

Table 10.5.2-53: 200 (OK) (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 
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54. 200 (OK) (P-CSCF to UE) - see example in table 10.5.2-54 

P-CSCF#1 forwards the 200 (OK) final response to UE#1. 

Table 10.5.2-54: 200 (OK) (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length : 

55. SIP BYE (UE to P-CSCF) - see example in table 10.5.2-55 

Upon receiving the notification of successful refer operation (49), UE#2 terminates the session with UE#1. 

Table 10.5.2-55: SIP BYE (UE to P-CSCF) 

BYE sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : eee : f f f : aaa : bbb] ; branch=z9hG4bK834y72 . 2 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: tel : +1-212-555-2222; tag=3 14 159 

To : sip : userl_publicl@homel .net;tag=17182 8 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 131 BYE 

Content-Length: 

Via: Contains the IP address or FQDN of the originating UE. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause 'Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

From:/To:/Call-ID: Contain the values previously used to establish the session, including the tag value from the 
response. Since this request is being initiated by the destination, the From and To are 
reversed. 

Cseq: Next higher sequential value. 

56. SIP BYE (P-CSCF to S-CSCF) - see example in table 10.5.2-56 

P-CSCF adds a Route header, with the saved value corresponding to the session. 
P-CSCF#2 forwards the BYE request to S-CSCF#2. 

Table 10.5.2-56: SIP BYE (P-CSCF to S-CSCF) 

BYE sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ;branch=z9hG4bK876t 12 . 1, SIP/2. 0/UDP 
[5555: :eee:fff :aaa:bbbl ; branch=z9hG4bK834y72 . 2 
Max-Forwards: 69 

Route: sip: scscf 2 .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscf 1 .homel . net; Ir 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

P-Access-Network-Info: this header contains information from the UE and shall be removed and stored by the S- 
CSCF. 

Route: Saved from the 200 (OK) response to the initial INVITE. 
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57. SIP BYE (S-CSCF to S-CSCF) - see example in table 10.5.2-57 

S-CSCF#2 forwards the SIP BYE request to S-CSCF#1. 

Table 10.5.2-57: SIP BYE (S-CSCF to S-CSCF) 

BYE sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

pcscf2.home2.net;branch=z9hG4bK87 6tl2. 1, S IP /2. 0/UDP [5555: : eee : f f f : aaa : bbb] ; branch=z9hG4bK834y72 . 2 

Max-Forwards: 68 

Route: sip: scscf 1 .homel . net; Ir, sip:pcscf 1 .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

58. SIP BYE (S-CSCF to P-CSCF) - see example in table 10.5.2-58 

S-CSCF#1 forwards the SIP BYE request to P-CSCF#1. 

Table 10.5.2-58: SIP BYE (S-CSCF to P-CSCF) 

BYE sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP pcscf 2 .home2 . net ; branch=z9hG4bK87 6t 12 . 1, 

SIP/2. 0/UDP [5555: : eee : f f f : aaa :bbb] ;branch=z9hG4bK834y72 . 2 

Max-Forwards : 67 

Route: sip:pcscfl .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

59. SIP BYE (P-CSCF to UE) - see example in table 10.5.2-59 

P-CSCF#2 forwards the SIP BYE request to UE#2. 

Table 10.5.2-59: SIP BYE (P-CSCF to UE) 

BYE sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1 

Max-Forwards: ^^ 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

60. 200 (OK) (UE to P-CSCF) - see example in table 10.5.2-60 

UE#2 acknowledges receipt of the SIP BYE request (59) with a 200 (OK) final response, sent to P-CSCF#1. 

Table 10.5.2-60: 200 (OK) (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 
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61. 200 (OK) (P-CSCF to S-CSCF) - see example in table 10.5.2-61 

P-CSCF#1 forwards the 200 (OK) final response to S-CSCF#1. 

Table 10.5.2-61 : 200 (OK) (P-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP pcscf 2 .home2 . net ; branch=z9hG4bK87 6t 12 . 1, 

SIP/2. 0/UDP [5555: : eee : f f f : aaa :bbb] ;branch=z9hG4bK834y72 . 2 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

P-CSCF restores the Via headers from the branch value in its Via. 
62. 200 (OK) (S-CSCF to S-CSCF) - see example in table 10.5.2-62 

S-CSCF#1 forwards the 200 (OK) final response to S-CSCF#2. 

Table 10.5.2-62: 200 (OK) (S-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

pcscf2.home2.net;branch=z9hG4bK87 6tl2. 1, S IP /2. 0/UDP [5555: : eee : f f f : aaa : bbb] ; branch=z9hG4bK834y72 . 2 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

63. 200 (OK) (S-CSCF to P-CSCF) - see example in table 10.5.2-63 

S-CSCF#2 forwards the 200 (OK) final response to P-CSCF#2. 

Table 10.5.2-63: 200 (OK) (S-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1, SIP/2. 0/UDP 
[5555: :eee:fff :aaa:bbb] ; branch=z9hG4bK834y72 . 2 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

64. 200 (OK) (P-CSCF to UE) - see example in table 10.5.2-64 

P-CSCF#2 forwards the 200 (OK) final response to UE#2. 

Table 10.5.2-64: 200 (OK) (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : eee : f f f : aaa:bbb] ; branch=z9hG4bK834y72 . 2 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



1 0.5.3 Session Transfer replacing an existing session 

Void. 
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10.6 IMS Message Exchange, UEs in different networks 
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Figure 10.6-1 Message exchange, UEs in different networlts 

Figure 10.6-1 shows two IMS UEs exchanging a Message. The details of the flows are as follows: 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 464 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

1. MESSAGE request (UE to P-CSCF#1) - see example in table 10.6-1 

UE#1 sends the MESSAGE request to the P-CSCF. 

Table 10.6-1 MESSAGE request (UE to P-CSCF#1) 

MESSAGE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Preferred- Identity; <sip; userl_publicl@homel . net> 

Privacy; none 

From; <sip ; userl_publicl@homel .net>;tag=31415 

To ; <sip;user2_publicl@home2 . net> 

Call- ID; b8 9r jhnedlrf jflslj40a222 

CSeq; 129 MESSAGE 

Content-Type; text/plain 

Content-Length; (...) 

The address is; 650 Route des Lucioles - Sophia Antipolis. From the airport take the A8 
towards Cannes . 

Request URI: Public user identity of the subscriber subscribes that the MESSAGE request is being sent to. In 
this case the PubHc User Identity of the user in SIP URI format. 

Privacy: the user does not require privacy, therefore the Privacy header is set to the value "none" as 

specified in RFC 3325 [17] and RFC 3323 [13]. 

P-Preferred-Identity: the user provides a hint about the identity to be used. 

From: This field is populated with the SIP URI containing the logical representation (FQDN) for the 

entity sending the MESSAGE request. 

To: Same as the Request-URL 



2. MESSAGE request (P-CSCF#1 to S-CSCF#1) - see example in table 10.6-2 

P-CSCF looks up the serving network information for the public user identity that was stored during the 
registration procedure. The MESSAGE request is forwarded to S-CSCF. A Route header is inserted into 
MESSAGE request. The information for the Route header is taken from the service route determined during 
registration. 

Table 10.6-2 MESSAGE request (P-CSCF#1 to S-CSCF#1) 

MESSAGE sip; user2_publicl@home2.net SIP/2.0 

Via; SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1 , SIP/2. 0/UDP 
[5555 ; ; aaa; bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

P -Asserted- Identity ; <sip ; userl„publicl@homel . net> 
Privacy ; 

Route; <sip; scscfl .homel . net; lr> 
From; 
To; 
CSeq; 

Content-Type ; 
Content-Length ; 

(...) 

P-Asserted-Identity: P-CSCF inserts the SIP URI in the P-Asserted-Identity header field and it also removes P- 
Preferred-Identity header field. 

Route: The Route: header field is populated with the Service Route from Registration. 

3. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. In this example 
there are no Service Points of Interest in this Request. 
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4. MESSAGE request (S-CSCF#1 to I-CSCF#2) - see example in table 10.6-4 

The S-CSCF forwards the MESSAGE request to an I-CSCF in the destination network. 

Table 10.6-4 MESSAGE request (S-CSCF#1 to l-CSCF#2) 

MESSAGE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

P -Asserted- Identity : <sip : userl_publicl@homel .net>, <tel: +1-2 12-555-1 111> 

Privacy : 

Route : <sip : icscf 2_s . home 2 . net ; lr> 

From: 

To: 

CSeq: 

Content-Type : 

Content-Length : 

(...) 

P-Asserted-Identity: S-CSCF inserts the TEL URI of the user in the P-Asserted-Identity header field. 

5. CX-User-Location Querry 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the terminating subscriber. The HSS 
responds with the address of the current S-CSCF for the terminating subscriber. 

6. MESSAGE request (I-CSCF#2 to SCSCF#2) - see example in table 10.6-6 

The I-CSCF forwards the MESSAGE request to the S-CSCF that serves the subscriber that the message is 
destined for. 

Table 10.6-6 MESSAGE request (l-CSCF#2 to S-CSCF#2) 

MESSAGE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2.net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

P -Asserted- Identity: 

Privacy : 

Route: <sip: scscf2 .home2 . net; lr> 

From: 

To: 

CSeq: 

Content-Type : 

Content-Length : 

(...) 

7. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. In this example 
there are no Service Points of Interest in this Request. 

8. MESSAGE request (S-CSCF#2 to P-CSCF#2) - see example in table 10.6-8 

The S-CSCF rewrites the Request-URI to the registered contact of the destination UE and forwards the 
MESSAGE request to the P-CSCF based on the Path header obtained at registration. 

Table 10.6-8 MESSAGE request (S-CSCF#2 to P-CSCF#2) 

MESSAGE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf2.home2.net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP icscf2_s.home2.net; 

branch=z9hG4bK871yl2. 1, SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 66 

P -Asserted- Identity: 

Privacy : 
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Route: <sip;pcscf 2 .home2 . net; lr> 

From: 

To: 

CSeq: 

P-Called-Party-ID : <sip:user2_publicl@home2 . net> 

Content-Type : 

Content-Length : 



(...) 



P-Called-Party-ID: S-CSCF inserts the contents of the original Request URI in the P-Called-Party-ID header field. 

9. MESSAGE request (P-CSCF#2 to UE#2) - see example in table 10.6-9 

The S-CSCF rewrites the Request-URI to the registered contact of the destination UE and forwards the 
MESSAGE request to the P-CSCF based on the Path header obtained at registration. 

Table 10.6-9 MESSAGE request (P-CSCF#2 to UE#2) 

MESSAGE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .home2 .net;branch=z9hG4bK876tl2 . 1 

Max-Forwards : 65 

P -As sorted- Identity: 

Privacy : 

From: 

To: 

CSeq: 

P-Called-Party-ID : 

Content-Type : 

Content-Length : 

(...) 

10. 200 (OK) response (PS to S-CSCF) - see example in table 10.6-10 

UE#2 sends the response to P-CSCF#2. 

Table 10.6-10: 200 (OK) response (UE#2 to P-CSCF#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ; branch=z9hG4bK876t 12 . 1 

From: 

To : <sip : userl_publicl@homel .net>;tag=151170 

Call-ID: 

CSeq: 

Content-Length: 

1 1. 200 (OK) response (P-CSCF#2 to S-CSCF#2) - see example in table 10.6-11 

P-CSCF#2 forwards the response to S-CSCF#2. 

Table 10.6-11 : 200 (OK) response (P-CSCF#2 to S-CSCF#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/ 2. 0/UDP scscf 1 . home 1 . net ; branch=z9hG4bK332b2 3 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

12. 200 (OK) response (S-CSCF#2 to I-CSCF#2) - see example in table 10.6-12 

S-CSCF#2 forwards the response to I-CSCF#2. 
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Table 10.6-12: 200 (OK) response (S-CSCF#2 to l-CSCF#2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: To: Call-ID: 

CSeq: 

Content-Length : 

13. 200 (OK) response (I-CSCF#2 to S-CSCF#1) - see example in table 10.6-13 

I-CSCF#2 forwards the response to S-CSCF#1. 

Table 10.6-13: 200 (OK) response (l-CSCF#2 to S-CSCF#1) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

14. 200 (OK) response (S-CSCF#1 to P-CSCF#1) - see example in table 10.6-14 

S-CSCF#1 forwards the response to P-CSCF#1. 

Table 10.6-14: 200 (OK) response (S-CSCF#1 to P-CSCF#1) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

15. 200 (OK) response (P-CSCF#1 to UE#1) - see example in table 10.6-15 

P-CSCF#1 forwards the response to UE#1. 

Table 10.6-15: 200 (OK) response (P-CSCF#1 to UE#1) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



1 1 Void 

This clause is intentionally left void. 



12 Void 

This clause is intentionally left void. 
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13 Void 



This clause is intentionally left void. 



14 



Void 



This clause is intentionally left void. 



15 Void 



This clause is intentionally left void. 



1 6 Signalling flows for REGISTER (hiding) 

16.1 Introduction 

See subclause 6.1. 

16.2 Registration signalling: user not registered 

Figure 16.2-1 shows the registration signalling flow for the scenario when the user is not registered. For the purpose of 
this signalling flow, the subscriber is considered to be roaming. This flow also shows the authentication of the private 
user identity. In this signalling flow, the home network has network configuration hiding active. 
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Figure 16.2-1 : Registration when UE roaming 

1 . GPRS Attach / PDP Context Establishment and P-CSCF Discovery (UE to GPRS) 

This signalling flow is shown to indicate prerequisites for the registration signalling. 
See subclause 5.2 for details. 
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2. REGISTER request (UE to P-CSCF) - see example in table 16.2-2 

The purpose of this request is to register the user's SIP URI with a S-CSCF in the home network. This request 
is routed to the P-CSCF because it is the only SIP server known to the UE. In the following SIP request, the 
Contact field contains the user's host address. 

The P-CSCF will perform two actions, binding and forwarding. The binding is between the User's SIP 
address (userl_publicl@homel.net) and the host (terminal) address ([5555::aaa:bbb:ccc:ddd]) which was 
acquired during PDP context activation process. 

Table 16.2-2 REGISTER request (UE to P-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel .net>;tag=4fa3 

To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555: : aaa :bbb : ccc : ddd] > 

Call- ID: apb03a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel . net " , realm="registrar .homel . net ", nonce=""^ 

uri="sip: registrar. homel .net", response="" 

Security-Client: ipsec-3gpp; alg=hmac-sha-l-96; spi=12345678; portl=1357 

Require: sec-agree 

CSeq: 1 REGISTER 

Supported: path 

Expires: 7200 

Content-Length: 

Request-URI: The Request-URI (the URI that follows the method name, "REGISTER", in the first line) indicates 
the destination domain of this REGISTER request. The rules for routing a SIP request describe 
how to use DNS to resolve this domain name ("registrar.homel.net") into an address or entry point 
into the home operator's network (the I-CSCF). This information is stored in the USIM. 

Via: IPv6 PDP address of the SIP session allocated during the PDP Context Activation process. 

Max-Forwards: Set to 70 by the UE and used to prevent loops. 

From: This indicates the public user identity originating the REGISTER request. The public user identity 

may be obtained from the USIM. 

To: This indicates the public user identity being registered. This is the identity by which other parties 

know this subscriber. It may be obtained from the USIM. 

Contact: This indicates the point-of-presence for the subscriber - the IP address of the UE. This is the 

temporary point of contact for the subscriber that is being registered. Subsequent requests destined 
for this subscriber will be sent to this address. This information is stored in the P-CSCF and S- 
CSCF. 

Editor's note: It is for further study whether this information is stored in the HSS and the S-CSCF for the subscriber 
in order to support multiple registrations. 

Authorization: It carries authentication information. The private user identity (userl_private@homel.net) is 

carried in the username field of the Digest AKA protocol. The uri parameter (directive) contains 
the same value as the Request-URI. The realm parameter (directive) contains the network name 
where the username is authenticated. The Request-URI and the realm parameter (directive) value 
are obtained from the same field in the USIM, and therefore, are identical. In this example, it is 
assumed that a new UICC card was just inserted into the terminal, and there is no other cached 
information to send. Therefore, nonce and response parameters (directives) are empty. 

Supported: This header is included to indicate to the recipient that the UE supports the Path header. 

Upon receiving this request the P-CSCF will set it's SIP registration timer for this UE to the Expires time in 
this request. 
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3. DNS:DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
the DNS queries to locate the I-CSCF in the home network. The look up in the DNS is based on the domain 
name specified in the Request URI. 

The P-CSCF sends the REGISTER request - after local processing - to the address indicated in the Request- 
URI. When forwarding the REGISTER request the P-CSCF needs to specify the protocol, port number and 
IP address of the I-CSCF server in the home network to which to send the REGISTER request. The P-CSCF 
tries to find this information by querying the DNS. Since the Request-URI does not specify a numeric IP 
address, and the transport protocol and port are not indicated, the P-CSCF performs an NAPTR query for the 
domain specified in the Request-URI. 

Table 16.2-3a DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME=registrar. homel.net, QCLASS=IN, QTYPE=NAPTR 



The DNS records are retrieved according to RFC 3263 [14]. 

Table 16.2-3b DNS Query Response (DNS to P-CSCF) 



j OPCODE=SQUERY, RESPONSE, AA 














: QNAME=registrar .homel .net, QCLASS=IN, 


QTYPE=NAPTR 








1 registrar.homel.net IN NAPTR 


50 


50 


"s" 


"SIP+D2U" 


"" _sip.. 


_udp.registrar.homel.net '• 


1 IN NAPTR 


90 


50 


"s" 


"SIP+D2T" 


"" _sip.. 


_tcp.registrar.homel.net ; 


1 IN NAPTR 


100 


50 


"s" 


"SIPS+D2T" 


"" _sips 


._tcp.registrar.homel.net I 



Based on the order and preference of the NAPTR record and the local preference, UDP is preferred and the 
P-CSCF finds the I-CSCF by a DNS SRV lookup according to RFC 2782 [4]. 



Table 16.2-3c DNS: DNS Query (P-CSCF to DNS) 

I" "dPcbD'E = SQ'uERY" 

i QNAME=_sip. _udp.registrar.homel.net, QCLASS=IN, QTYPE=SRV 



The DNS records are retrieved according to RFC 2782 [4]. 

Table 16.2-3d DNS: DNS Query Response (DNS to P-CSCF) 



; OPCODE=SQUERY, RESPONSE, AA 












I QNAME=_sip._udp. registrar . homel . net. 


QCLASS=IN, QTYPE= 


= SRV 






I _sip._udp.registrar.homel.net 


IN SRV 1 


10 


5060 


i c s c f l_p 


homel.com | 




IN SRV 1 





5060 


icscf 7_p 


homel.com i 


1 icscfl_p.homel.net 


IN AAAA 




5555 


: aba ; dab 


aaa : daa I 


1 icscf7_p.homel.net 


IN AAAA 




5555 


:ala:b2b 


c3c:d4d ! 



In the Answer field of the query-response each I-CSCF is identified by its host domain name. The returned 
SRV Resource Records (RRs) are merged and ordered, and the selection technique (employing the Priority 
and Weight parameters returned in the RRs) as specified in RFC 2782 [4] is used to select the I-CSCF 
(i.e. the icscfl_p.homel.net). Since the Additional Data field of the query -response also contains the IP 
address of the selected I-CSCF (i.e. 5555::aba:dab:aaa:daa), a new query to the DNS is not required. 

Once the IP address of the I-CSCF is obtained, the P-CSCF forwards the REGISTER request to this IP 
address (i.e. 5555::aba:dab:aaa:daa) using the UDP protocol and port number 5060. 

4. REGISTER request (P-CSCF to I-CSCF) - see example in table 16.2-4 
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The P-CSCF needs to be in the path for all terminating requests for this user. To ensure this, the P-CSCF 
adds itself to the path for future requests. 

The P-CSCF binds the public user identity under registration to the Contact header supplied by the user. 

The P-CSCF adds also the P- Visited-Network-ID header with the contents of the identifier of the P-CSCF 
network. This may be the visited network domain name or any other identifier that identifies the visited 
network at the home network. 

This signalling flow shows the REGISTER request being forward from the P-CSCF to the I-CSCF in the 
home domain. 

Table 16.2-4 REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Path: <sip;pcscfl. visitedl. net; lr> 
Require; path 

P-Visited-Network-ID ; "Visited Network Number 1" 

P-Charging-Vector : icid-value=a834bcl92f e3; icid-generated-at= [5555 : : e9e : d8d: c7c :b6b] 
From; 
To: 

Contact : 
Call-ID: 

Authorization: Digest username="userl_private@homel . net " , realm="registrar . homel . net " , nonce="", 
uri="sip: registrar. homel .net", response="", integrity-protected="no" 
CSeq: 

Supported: 
Expires : 
Content-Length : 

Path: This is the address of the P-CSCF and is included to inform the S-CSCF where to route 

terminating sessions. 

Require: This header is included to ensure that the recipient correctly handles the Path header. If 

the recipient does not support the path header, a response will be received with a status 
code of 420 and an Unsupported header indicating "path". Such a response indicates a 
misconfiguration of the routing tables and the request has been routed outside the IM 
CN subsystem. 

P- Visited-Network-ID: It contains the identifier of the P-CSCF network at the home network. 

5. Cx: User registration status query procedure 

The I-CSCF makes a request for information related to the Subscriber registration status by sending the 
private user identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF 
required capabilities and the I-CSCF uses this information to select a suitable S-CSCF. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-5a provides the parameters in the REGISTER request (flow 4) which need to been sent to HSS. 

6. REGISTER request (I-CSCF to S-CSCF) - see example in table 16.2-6 

I-CSCF adds a proper I-CSCF URI to the Path header. 

This signalling flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. The Request- 
URI is changed to the address of the S-CSCF. 

Table 16.2-6 REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP icscfl_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
Path: <sip : icscfl_p . homel . net ; lr>, <sip:pcscfl .visitedl . net; lr> 
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Require ; 

P-Visited-Network-ID : 

P-Charging-Vector ; 

From; 

To: 

Contact ; 

Call-ID: 

Authorization : 

CSeq: 

Supported: path 

Expires : 

Content-Length : 



Path: The S-CSCF stores the contents of the Path header and uses these URIs for routing mobile 

terminated sessions. 

Upon receiving this request the S-CSCF will set it's SIP registration timer for this UE to the Expires time in 
this request. 

7. Cx: S-CSCF authentication procedure 

As the REGISTER request arrived without integrity protection to the P-CSCF, the S-CSCF shall challenge it. 
For this, the S-CSCF requires at least one authentication vector to be used in the challenge to the user. If a 
valid AV is not available, then the S-CSCF requests at least one AV from the HSS. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-7a provides the parameters in the REGISTER request (flow 6) which need to be sent to HSS. 

8. Authentication vector selection 

The S-CSCF selects an authentication vector for use in the authentication challenge. For detailed description 
of the authentication vector, see 3GPP TS 33.203. 

NOTE 1 : The authentication vector may be of the form 3GPP TS 33.203 (if IMS AKA is the selected 
authentication scheme): 



RAND: random number used to generate the XRES, CK, IK, and part of the AUTN. It is also used 
to generate the RES at the UE. 

- AUTN: Authentication token (including MAC and SQN). 

- XRES: Expected (correct) result from the UE. 
CK: Cipher key (optional). 

IK: Integrity key. 
9. 401 Unauthorized response (S-CSCF to I-CSCF) - see example in table 16.2-9 

The authentication challenge is sent in the 401 Unauthorized response towards the UE. 

Table 16.2-9: 401 Unauthorized response (S-CSCF to I-CSCF) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 

To : <sip : userl_publicl@homel .net>;tag=5ef4 
Call-ID: 

www-Authenticate: Digest realm="registrar .homel . net ", nonce=base64 (RAND + AUTN + server specific 
data) , algorithm=AKAvl-MD5, ik="00112233445566778899aabbccddeef f ", 
ck="ffeeddccbbaal 122334455 6677 8 8 990 0" 
CSeq: 
Content-Length : 
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WWW-Authenticate: The S-CSCF challenges the user. The nonce includes the quoted string, base64 encoded value 
of the concatenation of the AKA RAND, AKA AUTN and server specific data. The S-CSCF 
appends also the Integrity Key (IK) and the Cyphering key (CK). 

NOTE: The actual nonce value in the WWW-Authenticate header field is encoded in base64, and it may look 
like:nonce="A34Cnn-Fva37UYWpGNB34JP" 

10. 401 Unauthorized response (I-CSCF to P-CSCF) - see example in table 16.2-10 

The authentication challenge is sent in the 401 Unauthorized response towards the UE. 

Table 16.2-10: 401 Unauthorized response (I-CSCF to P-CSCF) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 

www-Authenticate : 
CSeq: 
Content-Length : 

1 1. 401 Unauthorized response (P-CSCF to UE) - see example in table 16.2-11 

The P-CSCF removes any keys received in the 401 Unauthorized response and forwards the rest of the 
response to the UE. 

Table 16.2-11 : 401 Unauthorized response (P-CSCF to UE) 

SIP/2.0 401 Unauthorized 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

www-Authenticate: Digest realm="registrar .homel . net ", nonce=base64 (RAND + AUTN + server specific 

data) , algorithm=AKAvl-MD5 

Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

CSeq: 

Content-Length : 

WWW-Authenticate: The P-CSCF removes the ik and ck parameters (directives) from the header. 



12. Generation of response and session keys at UE 

Upon receiving the Unauthorized response, the UE extracts the MAC and the SQN from the AUTN. The UE 
calculates the XMAC and checks that XMAC matches the received MAC and that the SQN is in the correct 
range. If both these checks are successful the UE calculates the response, RES, and also computes the session 
keys IK and CK. The RES is put into the Authorization header and sent back to the registrar in the 
REGISTER request. 

13. REGISTER request (UE to P-CSCF) - see example in table 16.2-13 

Table 16.2-13 REGISTER request (UE to P-CSCF) 

REGISTER sip:registrar. homel. net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel .net>;tag=4fa3 

To: <sip : userl_publicl@homel . net>; tag=5ef4 

Contact: <sip: [5555: : aaa: bbb: ccc : ddd] > 

Call- ID: apb03a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 

nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 

uri="sip: registrar. homel .net", response="662 9fae4 93 93a053 97450 97 8507c4efl" 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

CSeq: 2 REGISTER 
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Supported: path 
Expires: 7200 
Content-Length: 



Authorization: This carries the response to the authentication challenge received in step 1 1 along with the private 
user identity , the realm, the nonce, the URI and the algorithm. 

14. DNS: DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
the DNS queries to locate the I-CSCF in the home network. The look up in the DNS is based on the domain 
name specified in the Request URI. 

The P-CSCF sends the REGISTER request - after local processing - to the address indicated in the Request- 
URI. When forwarding the REGISTER request the P-CSCF needs to specify the protocol, port number and 
IP address of the I-CSCF server in the home network to which to send the REGISTER request. The P-CSCF 
tries to find this information by querying the DNS. Since the Request-URI does not specify a numeric IP 
address, and the transport protocol and port are not indicated, the P-CSCF performs an NAPTR query for the 
domain specified in the Request-URI. 



Table 16.2-14a DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME=registrar. homel.net, QCLASS=IN, QTYPE=NAPTR 



The DNS records are retrieved according to RFC 3263 [14]. 

Table 16.2-1 4b DNS Query Response (DNS to P-CSCF) 



1 OPCODE=SQUERY, RESPONSE, AA 














1 QNAME=registrar .homel .net, QCLASS=IN, 


QTYPE=NAPTR 








! registrar.homel.net IN NAPTR 


50 


50 


"s" 


"SIP+D2U" 


"" _sip.. 


_udp.registrar.homel.net I 


I IN NAPTR 


90 


50 


"s" 


"SIP+D2T" 


"" _sip.. 


_tcp.registrar.homel.net ; 


: IN NAPTR 


100 


50 


"s" 


"SIPS+D2T" 


"" _sips 


._tcp.registrar.homel.net ', 



Based on the order and preference of the NAPTR record and the local preference, UDP is preferred and the 
P-CSCF finds the I-CSCF by a DNS SRV lookup according to RFC 2782 [4]. 

Table 16.2-14c DNS: DNS Query (P-CSCF to DNS) 



OPCODE=SQUERY 

QNAME= sip._udp.registrar.homel.net, QCLASS=IN, QTYPE=SRV 



The DNS records are retrieved according to RFC 2782 [4]. 

Table 1 6.2-1 4d DNS Query Response (DNS to P-CSCF) 



I OPCODE=SQUERY, RESPONSE, AA 

i QNAME= sip._udp.registrar.homel.net, QCLASS=IN, QTYPE=SRV 



_sip ._udp . registrar . homel . net 



I icscfl_p.homel.net 
I icscf7_p.homel.net 



IN SRV 1 10 5060 icscfl_p.homel.net 
IN SRV 1 5060 icscf7_p.homel.net 



IN AAAA 
IN AAAA 



5 5 5 5: : aba : dab : aaa : daa 
5555: :ala:b2b:c3c:d4d 



In the Answer field of the query-response each I-CSCF is identified by its host domain name. The returned 
SRV Resource Records (RRs) are merged and ordered, and the selection technique (employing the Priority 
and Weight parameters returned in the RRs) as specified in RFC 2782 [4] is used to select the I-CSCF 
(i.e. the icscfl_p.homel.net). Since the Additional Data field of the query -response also contains the IP 
address of the selected I-CSCF (i.e. 5555::aba:dab:aaa:daa), a new query to the DNS is not required. 
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Once the IP address of the I-CSCF is obtained, the P-CSCF forwards the REGISTER request to this IP 
address (i.e. 5555::aba:dab:aaa:daa) using the UDP protocol and port number 5060. 

15. REGISTER request (P-CSCF to I-CSCF) - see example in table 16.2-15 

This signalling flow shows the REGISTER request being forwarded from the P-CSCF to the I-CSCF in the 
home domain. 

Table 16.2-15 REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Path: <sip:pcscfl. visitedl. net; lr> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P-Charging-Vector : icid-value=a834bcl92fe3; icid-generated-at= [5555 : : e9e : d8d: c7c:b6b] 
From: 
To: 

Contact : 
Call-ID: 

Authorization: Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5, 

uri="sip: registrar .homel . net", response="6629fae49393a05397450978507c4ef 1", integrity- 
protected="yes" 
CSeq: 

Supported: 
Expires : 
Content-Length : 

Path: This is the P-CSCF URI and is included to inform the S-CSCF where to route terminating 

sessions. 

16. Cx: User registration status query procedure 

The I-CSCF requests information related to the Subscriber registration status by sending the private user 
identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF required 
capabilities and the I-CSCF uses this information to select a suitable S-CSCF. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-16a provides the parameters in the REGISTER request (flow 15) which need to been sent to HSS. 

17. REGISTER request (I-CSCF to S-CSCF) - see example in table 16.2-17 

This signalling flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. 

Table 16.2-17 REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP icscfl„p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Path: <sip : icscfl_p . homel . net ; lr>, <sip:pcscfl .visitedl . net; lr> 
Require : 

P-Visited-Network-ID : 
P-Charging-Vector : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
CSeq: 

Supported: 
Expires : 
Content-Length : 
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Path: The I-CSCF adds an I-CSCF(THIG) to the list of URIs in the Path header. The S-CSCF stores the 

contents of the Path headers and uses these addresses for routing mobile terminated sessions. 

18. Authentication 

Upon receiving an integrity protected REGISTER request, carrying the authentication response, RES, the S- 
CSCF checks that the user's active XRES matches the received RES. If the check is successful then the user 
has been authenticated and the public user identity is registered in the S-CSCF. 

19. Cx: S-CSCF registration notification procedure 

On registering a user the S-CSCF informs the HSS that the user has been registered at this instance. The HSS 
stores the S-CSCF name for that subscriber. For a positive response, the HSS will include the user profile in 
the response sent to the S-CSCF. 

For detailed message flows see 3GPP TS 29.228. 

Table 6.2-19a provides the parameters in the SIP REGISTER request (flow 17) which need to been sent to 
HSS. 

20. 200 OK response (S-CSCF to I-CSCF) - see example in table 16.2-20 

The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful. This 
response will traverse the path that the REGISTER request took as described in the Via list. 

Table 16.2-20 200 OK response (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p.homel . net; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Path; <sip ; icscf l_p . homel . net ; lr>, <sip;pcscfl .visitedl . net; lr> 
Service-Route : <sip : icscf l_p . homel .net;lr>^ <sip:scscfl. homel .net; lr> 
From: 
To: 

Call-ID: 

Contact: <sip: [5555: : aaa:bbb: ccc : ddd] >; expires=7200 
CSeq: 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip:userl_public2@homel . net>, <sip:userl_public3@homel . net>, <sip: +1-212-555- 
llll@homel .net; user=phone> 
Content-Length : 

Service-Route: The S-CSCF inserts the Service-Route header value that includes an I-CSCF (THIG) and the own 
S-CSCF URL 

21. 200 OK response (I-CSCF to P-CSCF) - see example in table 16.2-21 

The I-CSCF translates the S-CSCF name in the Service-Route header. The I-CSCF forwards the 200 (OK) 
response from the S-CSCF to the P-CSCF indicating that Registration was successful. This response will 
traverse the path that the REGISTER request took as described in the Via list. 

Table 16.2-21 200 OK response (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Path: 

Service-Route : <sip : icscf l_p . homel .net;lr>, <sip:to]cen(scscfl. homel .net; Ir ) @ homel .net;to]cenized- 
by=homel . net> 
From: 
To: 

Call-ID: 
Contact : 
CSeq: 
Date: 

P-Associated-URI : 
Content-Length : 
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22. 200 OK response (P-CSCF to UE) - see example in table 16.2-22 

The P-CSCF saves the value of the Service-Route header and associates it with the UE. The P-CSCF then 
forwards the 200 (OK) response from the I-CSCF to the UE indicating that Registration was successful. 

Table 16.2-22 200 OK response (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Path: 

Service-Route : 

From: 

To: 

Call-ID: 

Contact : 

CSeq: 

Date: 

P-Associated-URI : 

Content-Length : 



1 6.3 Registration signalling: reregistration - user currently 
registered 

For the purpose of the reregistration signalling flow shown in figure 16.3-1, the subscriber is considered to be roaming. 
This flow also shows the authentication of the private user identity. In this signalling flow, the home network has 
network configuration hiding active. 

This signalling flow assumes: 

1 . That the same PDP Context allocated during the initial registration scenario is still used for reregistration. For 
the case when the UE does not still have an active PDP context then PDP context procedures from 
subclause 16.2 is completed first. 

Editor's Note: If the same PDP-Context is not available, is it guaranteed that the UE will get back the same IP 

address at this point? If this is not possible, would there be a problem with the binding in the P-CSCF 
(user_publicl @homel.net and [5555::aaa:bbb:ccc:ddd])?2. The DHCP procedure employed for P-CSCF 
discovery is not needed. 

2. The S-CSCF selection procedure invoked by the I-CSCF is not needed. 
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Figure 16.3-1: Reregistration when UE roaming 

1 . REGISTER request (UE to P-CSCF) - see example in table 16.3-1 

The registration expires in the UE. The UE reregisters by sending a new REGISTER request. This request is 
sent to the same P-CSCF with which the UE initially registered. The P-CSCF maintains the same binding 
between the User's SIP public address (userl_publicl@homel.net) and the host (terminal) address 
([5555::aaa:bbb:ccc:ddd]) which it established during the original registration. 



Table 16.3-1 REGISTER request (UE to P-CSCF) 



REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

From; <sip ; userl_publicl@homel .net>;tag=4fa3 

To; <sip;userl_publicl@homel . net>; tag=5ef4 

Contact; <sip; [5555; ; aaa; bbb; ccc ; ddd] > 

Call-ID; apb03a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 

nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 

uri=" sip; registrar. homel. net", response=" 662 9fae4 9393a053 97450 97 8507c4efl" 

Security-Client; ipsec-3gpp; alg=hmac-sha-l-96; spi=12345678; portl=1357 

Required; sec-agree 

CSeq; 3 REGISTER 

Supported; path 

Expires; 7200 

Content-Length; 

The header field usage is the same as for the initial registration scenario: 

From: This indicates the public user identity originating the REGISTER request. The public user identity 

may be obtained from the USIM. 

To: This indicates public user identity being registered. This is the identity by which other parties 

know this subscriber. 

Contact: This indicates the point-of-presence for the subscriber - the IP address of the UE. This is the 

temporary identifier for the subscriber that is being registered. Subsequent requests destined for 
this subscriber will be sent to this address. This information is stored in the P-CSCF. 
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Editor's note: It is for further study whether this information is stored in the HSS and the S-CSCF for the subscriber 
in order to support muhiple registrations. 

Authorization: It carries authentication information. The private user identity (userl_private@homel.net) is 

carried in the username field of the Digest AKA protocol. As this is a re-registration process, the 
cached information (realm, nonce, algorithm, uri, response) is also sent. 

NOTE 1 : The actual nonce value in the WWW-Authenticate header field is encoded in base64, and it may look 
like:nonce="A34Cm+Fva37UYWpGNB34JP" 

Request-URI: The Request-URI (the URI that follows the method name, "REGISTER", in the first line) indicates 
the destination domain of this REGISTER request. The rules for routing a SIP request describe 
how to use DNS to resolve this domain name ("homel.net") into an address or entry point into the 
home operator's network (the I-CSCF). This information is stored in the USIM. 

Supported: This header is included to indicate to the recipient that the UEsupports the Path header. 

Upon receiving this request the P-CSCF will detect that it already has a registration record for this UE and 
will reset it's SIP registration timer for this UE to the Expires time in this request. 

2. DNS:DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
the DNS queries to locate the I-CSCF in the home network. The look up in the DNS is based on the address 
specified in the Request URI. The DNS provides the P-CSCF with an address of the I-CSCF in the home 
network. The P-CSCF must not use the I-CSCF address cached as a result of the previous registration. 

3. REGISTER request (P-CSCF to I-CSCF) - see example in table 16.3-3 

This signalling flow shows the REGISTER request being forward from the P-CSCF to the I-CSCF in the 
home domain. 

Table 16.3-3 REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Path: <sip:pcscfl. visitedl. net; lr> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P-Charging-Vector : icid-value=a834bcl92f e3; icid-generated-at= [5555 : : e9e : d8d: c7c:b6b] 
From: 
To: 

Contact : Call-ID: 

Authorization: Digest username="userl_private@homel .net", realm="registrar .homel . net ", 
nonce=base54 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5, 

uri="sip: registrar. homel .net", response="662 9fae4 93 93a053 97450 97 8507c4efl", integrity- 
protected="yes" 
CSeq: 

Supported: path 
Expires : 
Content-Length : 

Path: This is the P-CSCF URI and is included to inform the S-CSCF where to route 

terminating sessions. 

Require: This header is included to ensure that the recipient correctly handles the Path header. If 

the recipient does not support the path header, a response will be received with a status 
code of 420 and an Unsupported header indicating "path". Such a response indicates a 
misconfiguration of the routing tables and the request has been routed outside the IM 

CN subsystem. 

P-Visited-Network-ID: It contains the identifier of the P-CSCF network at the home network. 

4. Cx: User registration status query procedure 
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The I-CSCF requests information related to the Subscriber registration status by sending the private user 
identity, public user identity and visited domain name to the HSS. Because the user has registered, the HSS 
returns the I-CSCF with the S-CSCF address for the subscriber 

For detailed message flows see 3GPP TS 29.228. 

For the parameters in the REGISTER request (flow 3), which are sent to the HSS, see table 6.2-5a. 

Table 6.3-4a provides the parameters in the SIP REGISTER request (flow 5), which are obtained from the 
information sent back from the HSS. 

5. REGISTER request (I-CSCF to S-CSCF) - see example in table 16.3-5 

This signalling flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. The Request- 
URI is changed to the address of the S-CSCF. 

I-CSCF adds a proper I-CSCF name to the Path header. 

Table 16.3-5 REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK24 0f 34 .1, SIP/ 2 .0/UDP 
[5555 ; : aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 

Path: <sip ; icscf l_p . homel . net ; lr>, <sip;pcscfl .visitedl . net; lr> 
Require ; 

P-Visited-Network-ID : 
P-Charging-Vector ; 
From; 
To: 

Contact : 
Authorization : 
Call-ID: 
CSeq: 

Supported: 
Expires : 
Content-Length : 

Path: The S-CSCF stores the contents of the Path header and uses these URIs for routing mobile 

terminated sessions. 

P-Visited-Network-ID: It contains the identifier of the P-CSCF network at the home network. 

Upon receiving this request the S-CSCF will detect that it already has a registration record for this UE and 
will reset it's SIP registration timer for this UE to the Expires time in this request. 

6. Update registration timer 

As the REGISTER request arrived integrity protected, the S-CSCF does not need to challenge the user, but just 
update the registration timer to the value requested by the user (if the policy of the network allows it). 

NOTE: The S-CSCF is allowed to challenge the user. If S-CSCF decides to challenge the user, the call flow will be 
similar to the one presented in section 16.2. 

7. 200 OK response (S-CSCF to I-CSCF) - see example in Table 16.3-7 

The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful. This 
response will traverse the path that the REGISTER request took as described in the Via list. 

Table 16.3-7 200 OK response (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Path: <sip : icscf l_p . homel . net ; lr>, <sip:pcscfl .visitedl . net; lr> 
Service-Route : <sip : icscf l_p . homel .net;lr>, <sip:scscfl. homel .net; lr> 
From: 
To: 
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Call-ID: 

Contact: <sip: [5555: : aaa:bbb: ccc : ddd] >; expires=7200 

CSeq: 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip:userl_public2@homel . net>, <sip:userl_public3@homel . net>, <sip: +1-212-555- 

llll@homel .net; user=phone> 

Content-Length : 

Service-Route: The S-CSCF inserts the Service-Route header value that includes an I-CSCF (THIG) and the own 
S-CSCF URL 

8. 200 OK response (I-CSCF to P-CSCF) - see example in Table 16.3-8 

The I-CSCF translates the S-CSCF name in the Service-Route header. The I-CSCF forwards the 200 (OK) 
response from the S-CSCF to the P-CSCF indicating that Registration was successful. This response will 
traverse the path that the REGISTER request took as described in the Via list. 

Table 16.3-8 200 OK response (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Path: 

Service-Route : <sip : icscf l_p . homel .net;lr>, <sip:token(scscfl. homel .net; Ir ) @homel .net;tokenized- 
by=homel . net> 
From: 
To: 

Call-ID: 
Contact : 
CSeq: 
Date: 

P-Associated-URI : 
Content-Length : 

9. 200 OK response (P-CSCF to UE) - see example in Table 16.3-9 

The P-CSCF saves the value of the Service-Route header and associates it with the UE. The P-CSCF then 
forwards the 200 (OK) response from the I-CSCF to the UE indicating that Registration was successful. 

Table 16.3-9 200 OK response (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Path: 

Service-Route : 

From: 

To: 

Call-ID: 

Contact : 

CSeq: 

Date: 

P-Associated-URI : 

Content-Length : 



16.4 Registration signalling: mobile initiated deregistration 

Figure 16.4-1 shows a signalling flow for mobile initiated deregistration. For the purposes of this deregistration 
signalling flow, the subscriber is considered to be roaming. In this signalling flow, the home network has configuration 
hiding active. 

This signalling flow assumes: 

1 . That the same PDF Context allocated during the initial registration scenario is still used for deregistration. For 
the case when the UE does not still have an active PDP context then PDP context procedures from 
subclause 16.2 must first be completed. 
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Editor's Note: If the same PDP-Context is not available, is it guaranteed that the UE will get back the same IP 

address at this point? If this is not possible, would there be a problem with the binding in the P-CSCF 
(user_publicl@homel.net and [5555::aaa:bbb:ccc:ddd])? 

2. The procedure employed for P-CSCF discovery is not needed. 

3. The S-CSCF selection procedure invoked by the I-CSCF is not needed. 
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Figure 16.4-1: Registration signalling: mobile initiated deregistration 

1 . REGISTER request (UE to P-CSCF) - see example in table 16.4-1 

The UE intends to de-register itself It does so by sending a new REGISTER request. This request looks 
similar as in reregister case, but the Expires header contains zero. This request is sent to the same P-CSCF 
with which the UE initially registered. 

Table 16.4-1 REGISTER (UE to P-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: <sip : userl_publicl@homel .net>;tag=4fa3 

To : <sip:userl_publicl@homel . net> 

Contact: <sip: [5555: : aaa :bbb : ccc : ddd] > 

Call-ID: apb03a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 

nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 

uri="sip: registrar .homel . net", response="6629fae49393a05397450978507c4ef 1" 

CSeq: 7 REGISTER 

Supported: path 

Expires : 

Content-Length: 



The header field usage is the same as for the initial registration scenario: 
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From: This indicates the pubHc user identity originating the REGISTER request. The public user identity 

may be obtained from the USIM. 

To: This indicates pubHc user identity. This is the identity by which other parties know this subscriber. 

Contact: This indicates the point-of-presence for the subscriber - the IP address of the UE. This is the 

temporary identifier for the subscriber that is being de-registered. 

Authorization: It carries authentication information. The private user identity is carried in the usernamed field of 
the Digest AKA protocol. The deregistration process also includes the cached information (realm, 
nonce, algorithm, uri, response). 

Request-URI: The Request-URI (the URI that follows the method name, "REGISTER", in the first line) indicates 
the destination domain of this REGISTER request. The rules for routing a SIP request describe 
how to use DNS to resolve this domain name ("homel.net") into an address or entry point into the 
home operator's network (the I-CSCF). This information is stored in the USIM. 

Expires: The value indicates the registration is being cancelled. 

Supported: This header is included to indicate to the recipient that the UE supports the Path header. 

Upon receiving this request the P-CSCF will reset the SIP registration timer for this UE to 0. 

2. DNS:DNS-Q 

Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs 
a DNS query to locate the I-CSCF in the home network. The look up in the DNS is based on the address 
specified in the Request URI. The DNS provides the P-CSCF with an address of the I-CSCF in the home 
network. The P-CSCF must not use the I-CSCF address cached as a result of the previous registration. 

3. REGISTER request (P-CSCF to I-CSCF) - see example in table 16.4-3 

This signalling flow shows the REGISTER request being forward from the P-CSCF to the I-CSCF in the 
home domain. 

Table 16.4-3 REGISTER request (P-CSCF to I-CSCF) 

REGISTER sip:registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Path: <sip:pcscfl. visitedl. net; lr> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 
From: 
To: 

Contact : 
Call-ID: 

Authorization: Digest username = "userl_private@homel . net ", realm="registrar . homel . net " , 
nonce=base64 (RAND + AUTN + server specific data) , algorithm=AKAvl-MD5, 

uri="sip: registrar .homel . net", response="6629fae49393a05397450978507c4ef 1", integrity- 
protected="yes" 
CSeq: 

Supported: 
Expires : 
Content-Length : 



Path: 



Require: 



P-Visited-Network-ID: 



This is the P-CSCF URI and is included to inform the S-CSCF where to route 
terminating sessions. 

This header is included to ensure that the recipient correctly handles the Path header. If 
the recipient does not support the path header, a response will be received with a status 
code of 420 and an Unsupported header indicating "path". Such a response indicates a 
misconfiguration of the routing tables and the request has been routed outside the IM 
CN subsystem. 

It contains the identifier of the P-CSCF network at the home network. 
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4. Cx: User registration status query procedure 

The I-CSCF requests information related to the Subscriber registration status by sending the private user 
identity, pubHc user identity and visited domain name to the HSS. Because the user has registered, the HSS 
returns the I-CSCF with the S-CSCF address for the subscriber 

For detailed message flows see 3GPP TS 29.228. 

For the parameters in the SIP REGISTER request (flow 3) which are sent to the HSS, see table 6.2-5a. 

Table 6.3-4a provides the parameters in the SIP REGISTER request (flow 5) which are obtained from the 
information sent back from the HSS. 

5. REGISTER (I-CSCF to S-CSCF) - see example in table 16.4-5 

I-CSCF adds a proper I-CSCF name to the Path header. 

This signalling flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. The Request- 
URI is changed to the address of the S-CSCF. 

Table 16.4-5 REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip: scscfl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p.homel . net; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 

Path; <sip ; icscf l_p . homel . net ; lr> <sip;pcscfl .visitedl . net; lr> 
Require ; 

P-Visited-Network-ID ; 
From; 
To; 

Contact ; 
Call-ID; 
Authorization ; 
CSeq; 

Supported; 
Expires ; 
Content-Length ; 

Upon receiving this request the S-CSCF will reset the SIP registration timer for this UE to 0. 

6. Cx: S-CSCF registration notification procedure 

The S-CSCF informs the HSS that the user is no longer registered and the S-CSCF either notifies the HSS to 
clear or requests to keep its location information for that subscriber. The HSS then either clears or keeps the 
S-CSCF name for that subscriber according to request. In both cases the state of the subscriber identity is 
stored as unregistered in the HSS and the S-CSCF. The HSS acknowledges the request. 

For detailed message flows see 3GPP TS 29.228. 

For the parameters in the SIP REGISTER request (flow 5), which are sent to the HSS, see table 6.2-7a. 

7. 200 OK (S-CSCF to I-CSCF) - see example in table 16.4-7 

The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that deregistration was successful. This 
request will traverse the path that the REGISTER request took as described in the Via list. The S-CSCF 
clears its information for that subscriber. 

Table 16.4-7 200 OK response (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : ; aaa:bbb; ccc : ddd] ; branch=z9hG4bKnashds7 

Path; <sip ; icscf l_p . homel . net ; lr>, <sip;pcscfl .visitedl . net; lr> 
Service-Route ; <sip ; icscf l_p . homel .net;lr>, <sip;scscfl. homel . net ; lr> 
From; 

To ; <sip ; userl_publicl@homel . net> 
Call- ID: apb03a0s0 9dkjdfglkj4 9111 
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Contact: <sip: [5555: : aaa:bbb: ccc: ddd] >; expires=0 

CSeq: 3 REGISTER 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel . net>, <sip : userl_public3@homel .net>, <s ip: +1-2 12-555- 

llll@homel , net ; user=phone> 

Content-Length: 

8. 200 OK (I-CSCF to P-CSCF) - see example in table 16.4-8 

The I-CSCF forwards the 200 (OK) response from the S-CSCF to the P-CSCF indicating that deregistration 
was successful. This response will traverse the path that the REGISTER request took as described in the Via 
Ust. 

Table 16.4-8 200 OK response (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ; branch=z9hG4bKnashds7 
Path: 

Service-Route : <sip: icscf l_p.homel . net; lr>, <s ip: token (scscfl .homel . net; Ir) @homel . net; tokenized- 
by=homel . net> 
From: 
To: 

Call-ID: 
Contact : 
CSeq: 
Date: 

P-Associated-URI : 
Content-Length : 

9. 200 OK (P-CSCF to UE) - see example in table 16.4-9 

The P-CSCF forwards the 200 (OK) response from the I-CSCF to the UE indicating that deregistration was 
successful. The P-CSCF clears its information for that subscriber after sending the acknowledgement to the 
UE. 



Table 16.4-9 200 OK response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Path: 

Service-Route : 

From: 

To: 

Call-ID: 

Contact : 

CSeq: 

Date: 

P-Associated-URI : 

Content-Length : 



1 6.5 UE subscription for the registration state event package 

This section describes the subscription procedure for the registration states event package, whereby the UE requests to 
be notified by the S-CSCF when the event has occurred. This is done using the information structure as indicated in 
3GPPTS 24.229 [16]. 

It is assumed that the user has registered prior to initiating subscription of an event. Also, the subscriber is considered to 
be roaming and the home network has network configuration hiding active. For this example the trigger point at the UE 
for sending out the SUBSCRIBE request is the 200 (OK) response of the user's registration. 

Editor's Note: The interaction between the explicit subscription procedure for the Event : reg event package and 
the registration procedures needs further consideration. For example: What are the appropriate timer 
values of Expires header for these procedures considering the signalling is over the radio interface? What 
is the status of the ongoing explicit subscription procedure (Event: reg event package) when the 
registration timer has expired? etc. 
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Figure 16.5-1 : UE subscription for the registration state event pacitage 
(with l-CSCF providing configuration independence) 

1. SUBSCRIBE request (UE to P-CSCF) - see example in table 16.5-1 

The UE generates a SUBSCRIBE request in order to subscribe for the reg event package. 
The From and To fields both will contain the UE's public address. 

Table 16.5-1 SUBSCRIBE request (UE to P-CSCF) 

SUBSCRIBE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Asserted-Identity ; "John Doe" <sip ; userl_publicl@homel . net> 

Privacy: none 

From; <sip ; userl_publicl@homel .net>;tag=31415 

To; <sip; userl_publicl@homel . net> 

Call- ID; b8 9r jhnedlrf jflslj40a222 

CSeq; 61 SUBSCRIBE 

Event ; reg 

Expires; 7200 

Accept ; application/cpim-pidf +xml 

Contact; <sip; [5555; ; aaa; bbb; ccc ; ddd] > 

Content-Length; 

Request URI: Public user identity whose events the subscriber subscribes to. In this case the subscribing user and 
the monitored user are identical. 

From: This field is populated with logical representation (FQDN) for the entity sending the SUBSCRIBE 

request. 

Privacy: the user does not require privacy, therefore the Privacy header is set to the value "none" as 

specified in draft-ietf-sip-asserted-identity [17] and draft-ietf-sip-privacy-general [13]. 

P-Asserted-Identity: the user provides a hint about the identity to be used for this session. 

Event: This field is populated with the value 'reg' to specify the use of the presence package. 

Accept: This field is populated with the value 'application/cpim-pidf+xml'. 

To: Same as the Request-URI. 

Contact: The contact information of the subscribing user. 
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Upon receiving the SUBSCRIBE request, the P-CSCF stores the following information about this dialog, for 
use in possible error recovery actions - see example in table 16.5-lb. 

Table 1 6.5-1 b: Storage of information at P-CSCF 



■ Requ 


est-URI: 


sip : user l_public 


l@homel . 


net 


; From 


: sip:userl_publicl@homel 


. net 


tag 


=31415 : 


[ To: 


sip ; userl_public@homel . ne 


t 






1 Call 


-ID: b89rjhnedlrf jflslj40 


a222 






i Cseq 


(2dest) : 


61 SUBSCRIBE 








1 Cseq 


(2orig) : 


none 








j Cont 


act (orig 


: sip : [5555 : : aaa 


:bbb 


ccc 


:ddd] i 



2. SUBSCRIBE request (P-CSCF to I-CSCF) - see example in table 16.5-2 

P-CSCF looks up the serving network information for the public user identity that was stored during the 
registration procedure. The SUBSCRIBE request is forwarded to I-CSCF. A Route header is inserted into 
SUBSCRIBE request. The information for the Route header is taken from the path header as gathered during 
registration. 

Table 16.5-2 SUBSCRIBE request (P-CSCF to I-CSCF) 

SUBSCRIBE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : sip : icscf l_p . homel .net;lr, sip:token(sip:scscfl. homel .net; Ir ) @homel .net;tokenized- 
by=homel . net 

Record-Route : sip:pcscfl. visitedl. net;lr 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content-Length : 

Route: The Route header is populated with the remaining elements from the Path header from 

Registration. 

P-Asserted-Identity: The P-CSCF inserts this header based on the user's hint present in the incoming P-Asserted- 
Identity header. 

3. SUBSCRIBE (I-CSCF to S-CSCF) - see example in table 16.5-3 

I-CSCF determines the S-CSCF name in the Route header field to retrieve the routeing information. I-CSCF 
then forwards the SUBSCRIBE request to the S-CSCF. 

Table 16.5-3 SUBSCRIBE (I-CSCF to S-CSCF) 

SUBSCRIBE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l„p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
Route: sip: scscfl .homel . net; Ir 

Record-Route : sip : icscf l_p . homel .net;lr, s ip:pcscfl. visitedl. net; Ir 
P-Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
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Contact : 
Content-Length ; 



Record-Route: The I-CSCF adds itself to the Record-Route header as it wants to stay on the routeing path for 
network hiding purposes. 

Upon receiving the INVITE, the S-CSCF stores the following information about this session, for use in 
possible error recovery actions - see example in table 16.5-3b. 

Table 16.5-3b: Storage of information at S-CSCF 

Request-URI : sip : userl_publicl@homel . net 
From: sip : user l_publicl@homel . net; tag=31415 
To: sip:userl_public@homel . net 
Call- ID: b8 9r jhnedlrf jflslj40a222 
Cseq(2dest) : 61 SUBSCRIBE 
Cseq(2orig) : none 

Route (2orig) : sip: icscf l_p.homel . net; Ir, sip:pcscf 1 . visitedl . net; Ir 
! Contact (orig) : sip: [5555 :: aaa:bbb: ccc: ddd] 

4. 202 (Accepted) response (S-CSCF to I-CSCF) - see example in table 16.5-4 

The S-CSCF sends an acknowledgement towards the UE indicating that the subscription was successful. This 
response will traverse the path that the SUBSCRIBE request took as described in the Via list. 

NOTE 1 : If the S-CSCF can process the SUBSCRIBE request and send the NOTIFY request immediately, it can 
send a 200 (OK) response instead of a 202 (Accepted) response. 

Table 16.5-4 202 (Accepted) response (S-CSCF to I-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : sip : icscf l_p . homel .net;lr, sip:pcscfl. visitedl. net; Ir 
P-As sorted- Identity : <sip:scscfl. homel . net> 
Privacy: none 
From: 

To : <sip : userl_publicl@homel .net>;tag=151170 
Call-ID: 
CSeq: 

Contact: sip: scscfl .homel . net 
Event : 
Expires : 
Content-Length: 

Expires: If value of the Expires header in SUBSCRIBE request is different from the one received in 

REGISTER method, then the value of Expires header in 202 (Accepted) response is set to match 
the value of Expires header in REGISTER method. 

Contact: This is populated with a identifier generated within the S-CSCF that will help it correlate refreshes 

for the SUBSCRIBE request. It is assumed to be the public user identity 'userl_publicr in this 
case. 

5. 202 (Accepted) response (I-CSCF to P-CSCF) - see example in table 16.5-5 

The I-CSCF forwards the 202 (Accepted) response to the P-CSCF. 

Table 16.5-5 202 (Accepted) response (I-CSCF to P-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscfl . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : sip : icscf l_p . homel .net;lr, sip:pcscfl. visitedl. net; Ir 

P -As sorted- Identity: 
Privacy : 
From: 
To: 
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Call-ID: 

CSeq: 

Event : 

Contact ; sip;token(sip:scscfl. homel . net ) @homel .net; token! zecl-by=homel .net 

Expires ; 

Content-Length : 

6. 202 (Accepted) response (P-CSCF to UE) - see example in table 16.5-6 

The P-CSCF sends the 202 (Accepted) response to the UE. 

Table 16.5-6 202 (Accepted) response (P-CSCF to UE) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P -Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Event : 
Contact 
Expires : 
Content-Length : 

7. NOTIFY request (S-CSCF to I-CSCF) - see example in table 16.5-7 

The S-CSCF sends a first NOTIFY request towards the UE in order to inform the UE about the registration 
status of the monitored user. 

In the example below, the NOTIFY request specifies the following public user identities as registered (i.e. 
status=open): sip: user l_publicl@homel.net, tel: H-498972233114; 

The following public user identity has been deregistered (i.e. status=closed) sip:userl_public2@homel.net. 
They are arranged in the preferred order of priority in this example. 

The Route header is constructed from the information saved at registration. 

Table 16.5-7 NOTIFY request (S-CSCF to I-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route: sip: icscfl_p. homel . net; Ir, sip:pcscf 1 . visitedl . net; Ir 

From: <sip : userl_publicl@homel .net>;tag=151170 

To : <sip : userl_publicl@homel .net>;tag=31415 

Call-ID: 

CSeq: 42 NOTIFY 

Contact: sip: scscfl .homel . net 

Subscript ion- St ate : active; expires=72 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl@homel . net "> 

<status><basic>open</basic></status> 
</tuple> 

< tuple name="sip : userl_public2@homel . net "> 

<status><basic>closed</basic></status> 
</tuple> 

<tuple name="tel:+4 98 972233114"> 

<status><basic>open</basic></status> 
</tuple> 

</presence> 
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From: The tag of this field matches that of the To; field in the received 200/202 response for the 

SUBSCRIBE request. 

Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or 'application/cpim- 
pidf+xml' if the Accept header was not present in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the subscriber's registration state is described as indicated 
in 3GPP TS 24.229 [16]. 

8. NOTIFY request (I-CSCF to P-CSCF) - see example in table 16.5-8 

The I-CSCF translates the S-CSCF address in the Via header and forwards the NOTIFY request to the P- 
CSCF. 

Table 16.5-8 NOTIFY request (I-CSCF to P-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 . 1) Shomel .net; tokenized-by=homel . net 

Max-Forwards: 69 

Route : sip:pcscfl.visitedl.net;lr 

From: 

To: 

Call-ID: 

Cseq: 

Contact : s ip: token (sip: scscfl .homel . net) @homel . net; tokenized-by=homel . net 

Subscription-State : 

Event : 

Content-Type : 

Content-Length : 

9. NOTIFY request (P-CSCF to UE) - see example in table 16.5-9 

The P-CSCF sends the NOTIFY request to the UE. 

Table 16.5-9 NOTIFY request (P-CSCF to UE) 

NOTIFY sip: [5555: :aaa:bbb:ccc:dddl SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Subscription-State : 

Event : 

Content-Type : 

Content-Length : 

10. 200 (OK) response (UE to P-CSCF) - see example in table 16.5-10 

UE responds with 200 (OK) response to the NOTIFY request. 

Table 16.5-10 200 (OK) response (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

1 1. 200 (OK) response (P-CSCF to I-CSCF) - see example in table 16.5-11 

P-CSCF forwards the 200 (OK) response to the I-CSCF. 
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Table 16.5-11 200 (OK) response (P-CSCF to l-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 . 1) @homel . net; token! zed-by=homel . net 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

12. 200 (OK) response (I-CSCF to S-CSCF) - see example in table 16.5-12 

I-CSCF determines the request and forwards response to S-CSCF. This confirms that notification is reached 
to the user. 

Table 16.5-12 200 (OK) response (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



1 6.6 P-CSCF subscription for the registration state event 
package 

This subclause describes the subscription procedure for the registration state event package, whereby the P-CSCF 
requests to be notified by the S-CSCF when the event has occurred. This is done using the 'reg' package. 

It is assumed that the user has registered prior to initiating subscription of an event. Also, the subscriber is considered to 
be roaming and the home network has network configuration hiding active. For this example the trigger point at the P- 
CSCF for sending out the SUBSCRIBE request is the 200 (OK) response of the user's registration. 

Editor's Note: The interaction between the explicit subscription procedure for the Event : reg event package and 
the registration procedures needs further consideration. For example: What are the appropriate timer 
values of Expires header for these procedures considering the signalling is over the radio interface? What 
is the status of the ongoing explicit subscription procedure (Event: reg event package) when the 
registration timer has expired? etc. 
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Figure 16.6-1 : P-CSCF subscription for thie registration state event pacl<age 
(withi l-CSCF providing configuration independence) 

1. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table 16.6-1 

The P-CSCF generates a SUBSCRIBE request in order to subscribe for the reg event package. 
The route is constructed from the monitored users path header as constructed during registration. 

Table 16.6-1 SUBSCRIBE request (P-CSCF to l-CSCF) 

SUBSCRIBE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1 

Max-Forwards; 70 

Route ; sip ; icscf l_p . homel .net;lr, sip;token(sip;scscfl. homel .net; Ir ) @homel .net;tokenized- 

by=homel . net 

P -Asserted- Identity ; sip;pcscfl. visitedl. net 

Privacy: none 

From; <sip;pcscfl. visitedl. net>;tag=3 14 15 

To ; <sip ; userl_publicl@homel . net> 

Call- ID: dre3 6d2v32gnlgiiomm72445 

CSeq: 61 SUBSCRIBE 

Event ; reg 

Expires: 7200 

Accept : application/cpim-pidf +xml 

Contact: <sip: userl_publicl%4 0homel .net@pcscfl. visitedl. net> 

Content-Length: 

Request URI: Identifies the resource to subscribe. 

Max-Forwards: Set to 70 by the P-CSCF and used to prevent loops. 

Route: The token containing a representation of the I-CSCF and S-CSCF allocated to this user, based on 

the registration information. 

From: This header is populated with the SIP URI that identifies the P-CSCF. 

To: The SIP-URI of the resource to which the subscription is sent.. 

Contact: This is where the NOTIFY requests for this subscription will be sent. It consists of the SIP URL- 

escaped public user identity at the P-CSCF. 

Event: This field is set to the value 'reg' to specify the use of the reg package 

Accept: This field is set to the value 'application/cpim-pidf-nxml'. 

2. SUBSCRIBE request (l-CSCF to S-CSCF) - see example in table 16.6-2 

l-CSCF determines the S-CSCF name in the Route header field to retrieve the routeing information. I-CSCF 
then forwards the SUBSCRIBE request to S-CSCF. 

Table 16.6-2 SUBSCRIBE request (l-CSCF to S-CSCF) 

SUBSCRIBE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 

pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1 

Max-Forwards: 69 

Record-Route : sip : icscf l_p . homel .net; Ir 

P -Asserted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Event : 

Expires : 

Accept : 

Contact : 

Content-Length : 
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Record-Route: The I-CSCF adds itself to the Record-Route header as it wants to stay on the routeing path for 
network hiding purposes. 

3. 202 (Accepted) response (S-CSCF to I-CSCF) - see example in table 16.6-3 

The S-CSCF sends an acknowledgement towards the P-CSCF indicating that the subscription was successful. 
This response will traverse the path that the SUBSCRIBE request took as described in the Via list. 

NOTE 1: If the S-CSCF can process the SUBSCRIBE request and send the NOTIFY request immediately, it can 
send a 200 (OK) response instead of a 202 (Accepted) response. 

Table 16.6-3 202 (Accepted) response (S-CSCF to I-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK240f34. 1 

Record-Route ; sip ; icscf l_p . homel .net; Ir 

From: 

To ; <sip ; userl_publicl@homel .net>;tag=151170 

Call-ID: 

CSeq: 

Contact: sip: scscfl .homel . net 

Event : 

Expires : 

Content-Length: 

4. 202 (Accepted) response (I-CSCF to P-CSCF) - see example in table 16.6-4 

The I-CSCF forwards 202 (Accepted) response to the P-CSCF. 

Table 16.6-4 202 (Accepted) response (I-CSCF to P-CSCF) 

SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 

Record-Route : sip : icscf l_p . homel .net; Ir 

From: 

To: 

Call-ID: 

CSeq: 

Contact : sip : token (sip : scscfl .homel . net) @homel . net; tokenized-by=homel . net 

Event : 

Expires : 

Content-Length : 

5. NOTIFY request (S-CSCF to I-CSCF) - see example in table 16.6-5 

The S-CSCF sends a first NOTIFY request towards the P-CSCF in order to inform the P-CSCF about the 
registration status of the monitored user. 

The Route header is constructed from the Record-Route header as constructed during subscription. 
Table 16.6-5 NOTIFY request (S-CSCF to I-CSCF) 

NOTIFY sip: user l_publicl%4 0homel .net@pcscf 1 .visitedl .net SIP/2 . 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route: sip: icscf l_p. homel .net; Ir 

From: <sip:userl_publicl@homel . net>; tag=151170 

To: <sip:pcscfl. visitedl. net>; tag=31415 

Call-ID: 

CSeq: 42 NOTIFY 

Contact: sip: scscfl .homel . net 

Subscript ion- St ate : active; expires = 72 

Event : reg 

Content-Type : application/cpim-pidf +xml 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : "> 

< tuple name="sip : userl_publicl(3homel . net "> 
<status><basic>closed</basic></status> 
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</tuple> 
</presence> 

Request-URI: The contents are the same as the Contact header in the SUBSCRIBE request. 

From: The tag of this field matches that of the To; field in the received 200/202 response for the 

SUBSCRIBE request. 

Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or 'application/cpim- 
pidf+xml' if the Accept header was not present in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the subscriber's registration state is described as indicated 
in 3GPP TS 24.229 [16]. 

6. NOTIFY request (I-CSCF to P-CSCF) - see example in table 16.6-6 

The I-CSCF translates the S-CSCF address in the Via header and forwards the NOTIFY request to the P- 
CSCF. 

Table 16.6-6 NOTIFY request (I-CSCF to P-CSCF) 

NOTIFY sip:userl_publicl%40homel .net@pcscf 1 .homel .net SIP/2.0 

Via: SIP/2. 0/UDP icscfl„p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 

scscf 1 . homel .net; branch=z9hG4bK332b23 . 1 ) @ homel .net; token! zecl-by=homel .net 

Max-Forwards; 69 

From; 

To; 

Call-ID; 

Cseq; 

Contact; sip;token(sip;scscfl. homel . net ) @ homel .net; token! zecl-by=homel .net 

Subscription-State ; 

Event ; 

Content-Type ; 

Content-Length ; 

7. 200 (OK) response (P-CSCF to I-CSCF) - see example in table 16.6-7 

P-CSCF forwards the 200 (OK) response to the I-CSCF. 

Table 16.6-7 200 (OK) response (P-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP icscf l_p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 

scscf 1 .homel . net;branch=z9hG4bK332b23 . 1) (?homel .net; tokenized-by=homel . net 

From; 

To; 

Call-ID; 

CSeq; 

Content-Length; 

8. 200 (OK) response (I-CSCF to S-CSCF) - see example in table 16.6-8 

I-CSCF determines the request and forwards response to S-CSCF. This confirms that notification is reached 
to the user. 

Table 16.6-8 200 (OK) response (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

From; 

To; 

Call-ID; 

CSeq; 

Content-Length ; 
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1 6.7 Notifying of the network initiated deregistration event (not 
provided) 

16.8 Network initiated re-authentication 

This subclause describes the notification that occurs when the S-CSCF assigned to that user requests re-authentication 
in the case where the user's home network provides network configuration hiding. 

It is assumed that user has registered and also subscribed to the registration state event before. Also, the subscriber is 
considered to be roaming and the home network operator does not desire to keep its internal configuration hidden from 
the visited network. 

After this procedure the user's UE might automatically initiate re-registration procedures. If the user fails to re-register 
the public user identity for which re-authentication was requested, the public user identity may be deregistered by S- 
CSCF. 



UE 



8. initiate Re- 
authentication 



Visited Network (visitedl .net) 



GPRS /DHCP 



4. NOTIFY 



5. 200 (OK) 



P-CSCF 
(pcscfl) 



Home Netwo* (home1.net) 



DNS 



l-CSCF 
(icscf1_p) 



3. NOTiFY 



6. 200 (OK) 



S-CSCF 
(scscfl) 



1.Networl< initiated 
re-autiientication 



2. NOTIFY 



7. 200 (OK) 



Figure 16.8-1: S-CSCF informs UE that networit initiated re-authentication is needed 
(with l-CSCF providing configuration independence) 

1 . Network initiated re-authentication (S-CSCF) 

The network-initiated re-authentication event for the private user identity user occurs at the S-CSCF. As the 
user has subscribed to the registration state event package this is the trigger point for the S-CSCF to notify 
the user about the event occurrence. 

2. SIP NOTIFY request (S-CSCF to I-CSCF) - see example in table 16.8-2 

The S-CSCF sends a NOTIFY request towards the UE in order to inform the UE about the occurrence of the 
network initiated re-authentication event. 

The Route header is constructed from the information saved at registration. 

Table 16.8-2 SIP NOTIFY request (S-CSCF to l-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route: sip: icscfl_p. homel . net; Ir, sip:pcscfl .visitedl . net; Ir 

From: <sip : userl_publicl@homel . net>; tag=151170 

To : <sip:userl_publicl@homel . net>; tag=31415 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 43 NOTIFY 

Subscript ion- St ate : active; expires=72 

Event : reg 

Contact: sip: scscfl .homel . net 

Content-Type : application/cpim-pidf +xml 

Content-Length: (...) 

<presence xmlns="urn : ietf : params : xml : ns : cpim-pidf : " 
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xmlns : registration="urn: ietf :params : xml : ns : cpim-pidf : registration"> 

< tuple name="sip ; userl_publicl@homel . net "> 
<status> 

<basic>open</basic> 

<registration>re-authenticate</registration> 
</status> 
</tuple> 
</presence> 



From: The tag of this field matches that of the To; field in the received 200/202 response for the 

SUBSCRIBE request. 

Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or 'application/cpim- 
pidf+xml' if the Accept header was not present in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the subscriber's registration state is described as indicated 
in 3GPP TS 24.229 [16]. 

3. SIP NOTIFY request (I-CSCF to P-CSCF) - see example in table 16.8-3 

The I-CSCF translates the S-CSCF address in the Via header and forwards the NOTIFY request to the P- 
CSCF. 

Table 16.8-3 SIP NOTIFY request (I-CSCF to P-CSCF) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 

scscf 1 . homel .net; branch=z9hG4bK332b23 . 1 ) @ homel .net; tokenized-by=homel .net 

Max-Forwards: 69 

Route : sip:pcscfl.visitedl.net;lr 

From: 

To: 

Call-ID: 

Cseq: 

Subscription-State : 

Event : 

Contact: sip:token(sip:scscfl. homel . net ) @ homel .net; tokenized-by=homel .net 

Content-Type : 

Content-Length : 

4. SIP NOTIFY request (P-CSCF to UE) - see example in table 16.8-4 

The P-CSCF sends the NOTIFY request to the UE. 

Table 16.8-4 SIP NOTIFY request (P-CSCF to UE) 

NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Max-Forwards: 68 

From: 

To: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Contact : 

Content-Type : 

Content-Length : 

5. SIP 200 (OK) response (UE to P-CSCF) - see example in table 16.8-5 

UE responds with a 200 (OK) response to the NOTIFY request. 

Table 16.8-5 SIP 200 (OK) response (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



6. SIP 200 (OK) response (P-CSCF to I-CSCF) - see example in table 16.8-6 

P-CSCF forwards the 200 (OK) response to the I-CSCF. 

Table 16.8-6 SIP 200 (OK) response (P-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p.homel . net; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 

scscf 1 . homel .net; branch=z9hG4bK332b23 . 1 ) @homel .net; tokenizecl-by=homel .net 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

7. SIP 200 (OK) response (I-CSCF to S-CSCF) - see example in table 16.8-7 

I-CSCF determines the request and forwards response to S-CSCF. This confirms that notification has reached 
theUE. 

Table 16.8-7 SIP 200 (OK) response (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



8. Re-authentication (UE) 

The UE now initiates the re-authentication procedures. 
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1 6.9 Registration error conditions 

1 6.9.1 Reregistration - failure of reregistration 

This signalling flow (see figure 16.9.1-1) is a continuation of the signalling flow in subclause 16.3 after reception of 
signalling flow 4. This signalling flow shows the recovery after a failure of the S-CSCF that had been assigned to the 
subscriber in a previous registration. 
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Figure 16.9.1-1 : Failure of previous S-CSCF during reregistration 
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Steps 1 through 4 are the same as the signalling flow in subclause 16.3. 

5 REGISTER request (I-CSCF to S-CSCF) - see example in table 16.9.1-5 

This signalling flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. The Request- 
URI is changed to the address of the S-CSCF. 

I-CSCF adds a proper I-CSCF name to the Path header. 

Table 16.9.1-5 REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscfl. homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Path : <sip : icscf l_p . homel .net;lr>, <sip:pcscfl. visitedl. net ;lr> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 
From: <sip : userl_publicl@homel . net>; tag=4f aS 
To : <sip : userl_publicl@homel . net> 
Contact: <sip: [5555: : aaa :bbb : ccc : ddd] > 
Call-ID: apb03a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel . net ", realm="registrar .homel . net ", 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5, uri="sip: registar. homel . net ", 
response="0alb04c8 9e54f0 9ab4 5e84d30e2 9f83a", integrity-protected="yes" 
CSeq: 10 REGISTER 
Supported: path 
Expires: 7200 
Content-Length: 

6 Timeout of reregister 

The I-CSCF times out, waiting for the response from the S-CSCF. 

Editor's Note; The value of the timer in this particular instance is FFS. Clearly the value of the timers in the P- 
CSCF and UE waiting for the response must be considered when choosing this value. 

7 Cx: User registration status query (Optional) 

The I-CSCF informs the HSS that the S-CSCF for the subscriber is unreachable and requests information 
related to the required S-CSCF capabilities from the HSS, The HSS sends the capability information required 
for S-CSCF selection. The I-CSCF uses this information to select a suitable S-CSCF. 

This step is optional. Depending on implementation, sufficient information may be available to the I-CSCF 
from Step 4, to allow the I-CSCF select an alternate S-CSCF. Alternative mechanisms (for example a CSCF 
management plane) would be used to enable the HSS learn of S-CSCF failure. In addition, the HSS will learn 
about the assignment of a new S-CSCF in Step 9. 

8 REGISTER request (I-CSCF to S-CSCF) - see example in table 16.9.1-8 

This signalling flow forwards the REGISTER request from the I-CSCF to the newly selected S-CSCF. The 
Request-URJ is changed to the address of the new S-CSCF. 

Table 16.9.1-8 REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscf2. homel. net SIP/2.0 

Via: 

Max-Forwards : 67 

Path: 

Require : 

P-Visited-Network-ID : 

From: 

To: 

Contact : 

Call-ID: 

Authorization : 

CSeq: 

Supported: 

Expires : 

Content-Length : 
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The next ten steps (9 tol8) are the same as in the normal reregistration case (steps 6 to 12 in subclause 16.3). 
9. REGISTER request (I-CSCF to S-CSCF) - see example in table 16.9.1-9 

This signalhng flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected. 

Table 16.9.1-9 REGISTER request (I-CSCF to S-CSCF) 

REGISTER sip:scscf2. homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34. 1, SIP/2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 

Path: <sip ; icscf l_p . homel . net ; lr>, <sip;pcscf 1 . visitedl . net; lr> 
Require : 

P-Visited-Network-ID : 
From: 
To: 

Contact : 
Call-ID: 
Authorization : 
CSeq: 

Supported: 
Expires : 
Content-Length : 

Path: The S-CSCF stores the contents of the Path header and uses these URIs for routeing mobile 

terminated sessions. 

The remaining steps (20-25) are the same as in the normal reregistration case (steps 17-22 in subclause 16.3) 

1 7 Signalling flows for session initiation (hiding) 

17.1 Introduction 

See subclause 7.1. 

17.2 Origination Procedures 

17.2.1 Introduction 

See subclause 7.2.1. 

17.2.2 M0#1b 

1 7.2.2.1 (M0#1 b) Mobile origination, roaming (S-S#2, MT#2 assumed) 

Figure 17.2.2.1-1 shows an origination procedure which applies to roaming subscribers when the home network 
operator desires to keep its internal configuration hidden from the visited network. The UE is located in a visited 
network, and determines the P-CSCF via the CSCF discovery procedure. During registration, the home network 
allocates an S-CSCF. The home network advertises an I-CSCF as the entry point from the visited network, who 
forwards requests to the S-CSCF. 

When registration is complete, P-CSCF knows the name/address of the next hop in the signalling path toward the S- 
CSCF, the I-CSCF. I-CSCF receives information in the request, from which it determines the name/address of the 
proper S-CSCF. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



503 



ETSI TS 124 228 V5.3.0 (2002-12) 



Visited Network 



Home Network 



UE#1 



P-CSCF 



- 1. INVITE — 
2. 100 Trying - 



l-CSCF 
(THIG) 



3. 
INVITE 



6. 100_ 
Trying 



13. Aut 

Resources 



12. 183 Session 
Progress 
norize QoS 



14. 183 Session 
Progress 

— 15. PRACK — 



- 22. 200 OK 



23. Resource 
Reservation 



24. UPDATE- 



31.200OK- 



35. 180 Ringing 
- 36. PRACK - 



43. 200 
OK 



16. PRACK - 



21. 200 OK 



-25. UPDATE - 



30. 200 OK 



34. 180 Ringing 



37. PRACK 



42. 200 
OK 



46. 200_ 

47. Approval of QoS Commit 



48. 200 OK- 
- 49. ACK — 



- 50. ACK - 



S-CSCF 



4. 
INVITE 
_5. 100 
Trying 



7. Eva uation of 
initial Filter Criteria 



11. 183 Session 
Progress 



17. PRACK - 



20. 200 OK - 



-27. UPDATE- 



29. 200 OK - 



33. 180 Ringing 



38. PRACK 



41 . 200 
OK 



45. 200 _ 
OK 



51. ACK - 



8. INVITE — ^ 

— 9. 100 Trying 

10. 183 Session _ 
Progress 



18. PRACK 

19. 200 OK - 



— 28. UPDATE— 

— 28. 200 OK — 
32. 180 Ringing 



39. PRACK 

40. 200 OK 



44. 200 
' OK 



-52. ACK - 



Figure 17.2.2.1-1: M0#1b 

Procedure MO#lb is as follows: 

1 . INVITE (UE to P-CSCF) - see example in table 17.2.2.1-1 

UE#1 determines the complete set of codecs that it is capable of supporting for this session. It builds a SDP 
containing bandwidth requirements and characteristics of each, and assigns local port numbers for each 
possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there 
may be multiple codec choices offered. 

For this example, assume UE#1 is capable of sending two simultaneous video streams, either H261 or MPV 
format, and two simultaneous audio streams, either AMR, G726-32, PCMU, or G728. 
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UE sends the INVITE request, containing an initial SDP, to the P-CSCF determined via the CSCF discovery 
mechanism. An example is contained in table 17.2.2.1-1. 

Table 17.2.2.1-1 : INVITE (UE to P-CSCF) 

INVITE user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Pref erred-Identity : "John Doe" <sip;userl„publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy; none 

From; sip ; userl_publicl@homel . net ; tag=171828 

To; sip ; user2_publicl@home2 . net 

Call- ID; Cb03a0s0 9a2sdfglkj4 90333 

Cseq; 127 INVITE 

Require; precondition 

Supported; lOOrel 

Contact; sip; [5555; ; aaa;bbb; ccc ; ddd] 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 3400 RTP/AVP 98 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;98 H261 

a=rtpmap; 99;MPV 

m=video 3402 RTP/AVP 98 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;98 H261 

a=rtpmap; 99;MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

Request-URI: Contains the public user identity of the called user. 

Via: Contains the IP address or FQDN of the originating UE. 

Privacy: the user does not require privacy, therefore the Privacy header is set to the value "none" as 

specified in draft-ietf-sip-asserted-identity [17] and draft-ietf-sip-privacy-general [13]. 

P-Preferred-Identity: the user provides a hint about the identity to be used for this session. 

P-Access_Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in 3GPP TS 24.229 [16]. 



Cseq: Is a random starting number. 
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Contact: Is a IP address or FQDN of the originating UE. 

SDP The SDP contains et of codecs supported by UE#1 and desired by the user at UE#1 for this 

session 

Upon receiving the INVITE, the P-CSCF stores the following information about this session, for use in 
possible error recovery actions - see example in table 17.2.2. 1-lb: 

Table 17.2.2.1 -lb: Storage of information at P-CSCF 



Request- 


-URI : sip: user2_publicl@home2 . 


net 


From 


sip:userl_publicl@homel .net, 


tag 


=171828 


To: sip 


user2_publicl@home2 .net 






Call- 


-ID 


Cb03a0s0 9a2sdfglkj4 90333 






CSeq 


127 INVITE 







Contact (local) : sip: [5555 : : aaa:bbb: ccc : ddd] 



2. 100 Trying (P-CSCF to UE) - see example in table 17.2.2.1-2 

P-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 17.2.2.1-2: 100 Trying (P-CSCF to UE) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. INVITE (P-CSCF to I-CSCF) - see example in table 17.2.2.1-3 

P-CSCF remembers (from the registration procedure) the request routing for this UE. This becomes the 
topmost Route header in the request. This next hop is the I-CSCF within the home network of UE#1. 

P-CSCF adds itself to the Record-Route header and Via header. 

P-CSCF examines the media parameters, and removes any choices that the network operator decides based 
on local policy, not to allow on the network. 

For this example, assume the network operator disallows H261 video encoding. 

The INVITE request is forwarded through this I-CSCF to the S-CSCF. 

Table 17.2.2.1-3: INVITE (P-CSCF to I-CSCF) 

INVITE sip:user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branc]i=z9]iG4bKnas]ids7 
Max-Forwards: 69 

Route : sip : icscf l_p . liomel .net;lr, sip:To]cen(sip:scscfl. liomel . net ; Ir ) @]iomel .net;tokenized- 
by=homel . net 

Record-Route : sip:pcscfl. visitedl. net;lr 

P-Asserted-Identity : "Jolin Doe" <sip:userl_publicl@]iomel . net> 
P-Access-Networlc-Inf o : 

P-Cliarging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Lengtli: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
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c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video 34 02 RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Route: 



Contains the elements from the Path header from registration. 



P-Asserted-Identity: The P-CSCF inserts this header based on the user's hint present in the incoming P-Preferred- 
Identity header. 

P-Charging- Vector: The P-CSCF inserts this header and populates the icid parameters with a unique value and the 
IP address of the P-CSCF. 

SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the video media streams no longer list code 98 (H261). 

4. INVITE (I-CSCF to S-CSCF) - see example in table 17.2.2.1-4 

I-CSCF adds itself to the Record-Route header, and adds a Via header. 

I-CSCF determines the routing information contained in the request, and forwards the request to S-CSCF that 
is serving the UE. 

Table 17.2.2.1-4: INVITE (I-CSCF to S-CSCF) 

INVITE sip:user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p.homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 ; ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 68 

Record-Route ; sip ; icscf l_p . homel .net;lr, sip;pcscfl. visitedl. net; Ir 
Route; sip; scscfl .homel . net; Ir 
P-Asserted-Identity ; 
P-Access-Network-Inf o ; 
P-Charging-Vector ; 
Privacy ; 
From; 
To; 

Call-ID; 
Cseq; 
Require ; 
Supported; 
Contact ; 
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Content-Type : 
Content-Length : 



P-Access-Network-Info: this header contains information from the UE and will be removed and stored by the S- 
CSCF. 

Upon receiving the INVITE, the S-CSCF stores the following information about this session, for use in 
possible error recovery actions - see example in table 17.2.2. l-4b: 

Table 17.2.2. 1-4b: Storage of information at S-CSCF 

■ Request-URI: sip: user2_publicl@home2.net 

I From: sip : userl_publicl@homel . net ; tag=171828 

To: tel:+l-212-555-2222;tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest) : 127 INVITE 

CSeq(2orig) : none 

Route(2orig) : sip : icscf l_p . homel . net ; Ir, sip:pcscf 1 . visitedl . net; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 

Contact (orig) : sip: [5555 : : aaa : bbb : ccc : ddd] 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 



5. 100 Trying (S-CSCF to I-CSCF) - see example in table 17,2.2,1-5 

S-CSCF responds to the INVITE request (4) with a 100 Trying provisional response. 

Table 17.2.2.1-5: 100 Trying (S-CSCF to I-CSCF) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, 
pcscfl .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 



SIP/2. 0/UDP 
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Call-ID: 
CSeq: 
Content-Length : 



6. 100 Trying (I-CSCF to P-CSCF) - see example in table 17.2.2.1-6 

I-CSCF forwards the 100 Trying provisional response to P-CSCF. 

Table 17.2.2.1-6: 100 Trying (I-CSCF to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

7. Evaluation of initial filter criteria 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criteria. 

8. INVITE (MO#lb to S-S) - see example in table 17.2.2.1-8 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 

S-CSCF forwards the INVITE request, as specified by the S-CSCF to S-CSCF procedures. 



Table 17.2.2.1-8: INVITE (M0#1b to S-S) 



INVITE sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscf l_p.homel . net; branch=z9hG4bK351g4 5 .1, SIP/2 . 0/UDP pcscf 1 .visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Record-Route: sip: scscf 1 .homel . net; Ir, sip: icscf l_p. homel . net; Ir, sip:pcscfl .visitedl . net; Ir 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 

Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 
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a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 
a=rtpmap:96 G726-32/8000 



SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the video media streams show a port number zero, which removes them from the negotiation. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 

9. 100 Trying (S-S to MO#lb) - see example in table 17.2.2.1-9 (related to 17.2.2.1-8) 

S-CSCF receives a 100 Trying provisional response, as specified by the S-CSCF to S-CSCF procedures. 

Table 17.2.2.1-9: 100 Trying (S-S to M0#1b) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

10. 183 Session Progress (S-S to MO#lb) - see example in table 17.2.2.1-10 (related to 17.2.2.1-8) 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response (to (8)), per the S-CSCF to S-CSCF procedures. 

Table 17.2.2.1-10: 183 Session Progress response (S-S to M0#1b) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .homel . net; Ir, sip: scscf 2 .homel . net; Ir, sip: scscf 1 .homel . net; Ir^ 

sip : icscf l_p . homel .net;lr, sip:pcscfl. visitedl. net; Ir 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@homel . net>, <tel : +l-212-555-2222> 

Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

From: 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 3 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 
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Upon receiving the 183 Session Progress, the S-CSCF stores the following information about this session, for 
use in providing enhanced services, charging or in possible error recovery actions - see example in table 
17.2.2.1-lOb. 

Table 17.2.2.1 -10b: Storage of information at S-CSCF 



Request-URI ; sip : user2_publicl@home2 . net 
From: <sip : userl_publicl@homel . net>; tag=171828 
To: <sip:user2__publicl@home2 .net>; tag=314159 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest) : 127 INVITE 
CSeq(2orig): none 

Route (2clest ) : sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 . visited2 . net; Ir 
Route(2orig) : sip : icscf l„p . homel . net ; Ir, sip : pcscf 1 . visitedl . net ; Ir 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
Contact (dest) : sip: [5555: :eee:fff: aaa:bbb] 
1 Contact (orig) : sip: [5555 :: aaa:bbb: ccc : ddd] 

1 1. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 17,2,2.1-11 
S-CSCF forwards the 183 Session Progress response to 1-CSCF. 

Table 17.2.2.1-11 : 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf l_p.homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : icid-value = 1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e661; ccf=[5555: :a55:b4 4:c33:d22]; 
ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging 
12. 183 Session Progress (I-CSCF to P-CSCF) - see example in table 17.2.2.1-12 
I-CSCF forwards the 183 Session Progress response to P-CSCF. 

Table 17.2.2.1-12: 183 Session Progress (I-CSCF to P-CSCF) 

SIP/2.0 183 Session Progress 
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Via: SIP/2. 0/UDP pcscf 1 . visitedl .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route ; sip;Token(sip;pcscf2. homel .net;lr, sip;scscf2. homel .net; Ir, 
scscf 1 . homel .net; Ir ) @ homel .net; tokenized-by=homel .net, sip : icscf l_p . homel .net, 
sip;pcscfl .visitedl . net 
P-Asserted- Identity: 
Privacy : 

P-Charging-Vector ; 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



Record-Route: Header entries of the home network of the I-CSCF are tokenized. The I-CSCF itself and the UE 
addresses are not subject to tokenization. 

Upon receiving the 183 Session Progress, the P-CSCF removes the Record-Route headers, calculates the 
proper Route header to add to future requests, and saves that information without passing it to UE. The saved 
value of the information for this session is as shown table 17.2.2.1-12b: 

Table 17.2.2.1 -12b: Storage of information at P-CSCF 

I Request-URI : sip: user2_publicl@home2.net 
From: sip : userl_publicl@homel . net ; tag=171828 
To: sip:user2_publicl@home2 . net 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest): 127 INVITE 
Cseq(2orig) : none 
Route(2dest) : sip: icscf l_p. homel . net; Ir, sip: Token (sip: scscf 1 .homel . net; Ir, 

sip: scscf2 . homel .net;lr, pcscf2. homel . net ; Ir ) ; tokenized-by=homel .net 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
Contact (orig) : sip: [5555 : : aaa:bbb: ccc : ddd] 
Contact (dest) : sip: [5555: :eee:fff: aaa:bbb] 

13. Authorize QoS Resources 

P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens 
at this stage or after 200 OK of INVITE (35) based on operator local policy. 

14. 183 Session Progress (P-CSCF to UE) - see example in table 17.2.2.1-14 

P-CSCF forwards the 183 Session Progress response to the originating endpoint. 

Table 17.2.2.1-14: 183 Session Progress (P-CSCF to UE) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P -Asserted- Identity: 

Privacy : 

P-Media-Authorization: 0020000100100101706466312e76697369746564322e6e6574000c02013942563330373200 
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From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdfl.visitedl.net" with credentials "9BV3072". "00" at the end of 
the authorization token is required to pad to a multiple of 4 bytes. 

15. PRACK (UE to P-CSCF) - see example in table 17.2.2.1-15 

UE decides the set of media streams for this session, and includes this information as a new SDP offer in the 
PRACK request to P-CSCF. 

Table 17.2.2.1-15: PRACK (UE to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To: 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 128 PRACK 

Require: precondition 

Rack: 9021 127 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

Request-URI: Takes the value of the Contact header of the received 183 Session Progress response. 

Via: Take the value of either the IP address of FQDN of the originating UE. 
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P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in 3GPP TS 24.229 [16]. 

From:/To:/Call-ID: Copied from the 183 Session Progress response so that they include any tag parameter. 

Cseq: Takes a higher value than that in the previous request. 

16. Resource Reservation 

After determining the final media streams in step #15, UE initiates the reservation procedures for the 
resources needed for this session. 

17. PRACK (P-CSCF to I-CSCF) - see example in table 17.2.2.1-17 

P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the PRACK request to I-CSCF. 

Table 17.2.2.1-17: PRACK (P-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Inf o : 

Route: sip: icscf l_p.homel . net; Ir, sip: Token (sip: scscfl .homel . net; Ir, sip: scscf 2 .homel . net; Ir, 
sip:pcscf2 . homel .net; Ir ) @ homel . net ; tokenized-by=homel .net 
From: 
To: 

Call-ID: 
Cseq: 

Require: precondition 
Rack: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c= 

t = 



Route: Saved from the Record-Route header of the 183 Session Progress response. 

18. PRACK (I-CSCF to S-CSCF) - see example in table 17.2.2.1-18 

I-CSCF determines the routing information, and forwards the PRACK request to S-CSCF. 

Table 17.2.2.1-18: PRACK (I-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
P-Access-Network-Inf o : 

Route: sip: scscf 1 .homel . net; Ir, sip: scscf2 .homel . net; Ir, sip:pcscf2 .homel . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
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Require: precondition 
Rack: 

Content-Type : 
Content-Length : 



P-Access-Network-Info: this header contains information from the UE and will be removed and stored by the S- 
CSCF. 

19. PRACK (MO#lb to S-S) - see example in table 17.2.2.1-19 

S-CSCF forwards the PRACK request to the terminating endpoint, as per the S-CSCF to S-CSCF procedure. 

Table 17.2.2.1-19: PRACK (M0#1b to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf2 .homel . net; Ir, sip:pcscf2 .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



20. 200 OK (S-S to MO#lb) - see example in table 17.2.2.1-20 (related to 17.2.2.1-19) 

The destination endpoint responds to the PRACK request (19) with a 200 OK response, per the S-CSCF to S- 
CSCF procedures. 



Table 17.2.2.1-20: 200 OK (S-S to M0#1b) 



SIP/2.0 200 OK 
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Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK24 0f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

21. 200 OK (S-CSCF to I-CSCF) - see example in table 17.2.2.1-21 

S-CSCF forwards the 200 OK response to I-CSCF. 

Table 17.2.2.1-21 : 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s = 
c= 

t = 



22. 200 OK (I-CSCF to P-CSCF) - see example in table 17.2.2.1-22 

I-CSCF forwards the 200 OK response to P-CSCF. 

Table 17.2.2.1-22: 200 OK (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
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Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



23. 200 OK (P-CSCF to UE) - see example in table 17.2.2.1-23 
P-CSCF forwards the 200 OK response to UE. 

Table 17.2.2.1-23: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



24. UPDATE (UE to P-CSCF) - see example in table 17.2.2.1-24 

When the resource reservation is completed, UE sends the UPDATE request to the terminating endpoint, via 
the signalling path established by the INVITE request. The request is sent first to P-CSCF. 

Table 17.2.2.1-24: UPDATE (UE to P-CSCF) 

UPDATE sip: [5555: : eee : f f f : aaa : bbb] SIP/ 2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To : sip : user2_publicl@home2 .net;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 129 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 
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v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

Request-URI: Takes the value of the Contact header of the received 183 Session Progress response. 

Via: Take the value of either the IP address or FQDN of the originating UE. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in 3GPP TS 24.229 [16]. 

From:/To:/Call-ID: Copied from the 183 Session Progress response so that they include any tag parameters. 

Cseq: Takes a higher value than that in the previous request. 

The SDP indicates that the resource reservation was successful in the local segment. 

25. UPDATE (P-CSCF to I-CSCF) - see example in table 17.2.2.1-25 

P-CSCF adds a Route header, with the saved value from the previous response. P-CSCF identifies the proper 
saved value by the Request-URI. 

P-CSCF forwards the UPDATE request to I-CSCF. 

Table 17.2.2.1-25: UPDATE (P-CSCF to I-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Inf o : 

Route : sip: icscf l_p.homel . net; Ir, sip: Token (sip :scscfl .homel . net; Ir, sip:scscf2 .homel . net; Ir, 
sip:pcscf2 . homel .net; Ir ) @ homel .net; tokenized-by=homel .net 

P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=l 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 
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Route: Saved from the Record-Route header of the 183 Session Progress response. 

26. UPDATE (I-CSCF to S-CSCF) - see example in table 17.2.2.1-26 

I-CSCF determines the routing information, and forwards the request to S-CSCF. 

Table 17.2.2.1-26: UPDATE (I-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p.homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
P-Access-Network-Inf o : 

Route: sip: scscf 1 .homel . net; Ir, sip: scscf 2 .homel . net; Ir, sip:pcscf 2 .homel . net; Ir 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 
s = 



P-Access-Network-Info: this header contains information from the UE and will be removed and stored by the S- 
CSCF. 

P-Charging- Vector: The P-CSCF added the GPRS access network information to this header, which is removed 
and stored by the S-CSCF. 

27. UPDATE (MO#lb to S-S) - see example in table 17.2.2.1-27 

S-CSCF forwards the UPDATE request to the terminating endpoint, as per the S-CSCF to S-CSCF 
procedure. 

Table 17.2.2.1-27 UPDATE (M0#1b to S-S) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 2 .homel . net; Ir, sip:pcscf 2 .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 
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28. 200 OK (S-S to MO#lb) - see example in table 17.2.2.1-28 (related to 17.2.2.1-27) 

The destination endpoint responds to the UPDATE request (27) with a 200 OK, per the S-CSCF to S-CSCF 
procedures. 

The SDP indicates that the resource reservation was successful both in the local and the remote segment. 
Table 17.2.2.1-28: 200 OK (S-S to M0#1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscf l_p.homel . net; branch=z9hG4bK351g4 5 .1, SIP/2 . 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 



29. 200 OK (S-CSCF to I-CSCF) - see example in table 17.2.2.1-29 

S-CSCF forwards the 200 OK response to I-CSCF. 

Table 17.2.2.1-29 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l„p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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30. 200 OK (I-CSCF to P-CSCF) - see example in table 17.2.2.1-30 

I-CSCF forwards the 200 OK response to P-CSCF. 

Table 17.2.2.1-30: 200 OK (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa ; bbb : ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



Record-Route: Entries to the left of I-CSCF's entry are reversed and translated. 
31. 200 OK (P-CSCF to UE) - see example in table 17.2.2.1-31 

P-CSCF forwards the 200 OK response to UE. 

Table 17.2.2.1-31 : 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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32. 180 Ringing (S-S to MO#lb) - see example in table 17.2.2.1-32 (related to 17.2.2.1-8) 

The called UE may optionally perform alerting. If so, it signals this to the calling party by a 180 Ringing 
provisional response to (8). This response is sent to S-CSCF per the S-CSCF to S-CSCF procedure. 



Table 17.2.2.1-32: 180 Ringing (S-S to M0#1b) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .homel . net; Ir, sip: scscf 2 .homel . net; Ir, sip: scscf 1 .homel . net; Ir, 

sip : icscf l_p . homel .net;lr, sip:pcscfl. visitedl. net; Ir 

From: 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 9022 

Content-Length: 

33. 180 Ringing (S-CSCF to I-CSCF) - see example in table 8.1.2-33 
S-CSCF forwards the 180 Ringing response to I-CSCF. 

Table 17.2.2.1-33: 180 Ringing (S-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf l_p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

34. 180 Ringing (I-CSCF to P-CSCF) - see example in table 17.2.2.1-34 
I-CSCF forwards the 180 Ringing response to P-CSCF. 

Table 17.2.2.1-34: 180 Ringing (I-CSCF to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : sip:To]cen(sip:pcscf2. homel .net;lr, sip:scscf2. homel .net;lr, sip:scscfl. homel .net; Ir ) 
@ homel .net; to]cenized-by=homel .net, sip : icscf l_p . homel .net;lr, sip:pcscfl. visitedl. net; Ir 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

Record-Route: Header entries of the home network of the I-CSCF are tokenized. The I-CSCF itself and the UE 
addresses are not subject to tokenization. 

35. 180 Ringing (P-CSCF to UE) - see example in table 17.2.2.1-35 
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P-CSCF removes the Record-Route headers. 
P-CSCF forwards the 180 Ringing response to UE. 

Table 17.2.2.1-35: 180 Ringing (P-CSCF to UE) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

36. PRACK (UE to P-CSCF) - see example in table 17.2.2.1-36 

UE indicates to the originating subscriber that the destination is ringing. It acknowledges the 180 Ringing 
provisional response (35) with a PRACK request. 

Table 17.2.2.1-36: PRACK (UE to P-CSCF) 

PRACK sip: [5555: : eee : f f f : aaa : bbb] SIP/ 2.0 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To : sip: user 2_publicl@home2 . net; tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 130 PRACK 

Rack: 9022 127 INVITE 

Content-Length: 

Request-URI: Takes the value of the Contact header of the 180 Ringing response. 

Via: Take the value of either the IP address or FQDN of the UE. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in 3GPP TS 24.229 [16]. 

From:/To:/Call-ID: Copied from the 180 Ringing response so that they include any revised tag parameters. 

Cseq: Takes a higher value than in the previous request. 

37. PRACK (P-CSCF to I-CSCF) - see example in table 17.2.2.1-37 

P-CSCF adds the Route header corresponding to the session, P-CSCF forwards the PRACK request to I- 
CSCF. 

Table 17.2.2.1-37: PRACK (P-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Inf o : 

Route: sip: icscf l_p.homel . net; Ir, sip: Token (sip: scscfl .homel . net; Ir, sip: scscf 2 .homel . net; Ir, 
sip:pcscf2 . homel .net; Ir ) @ homel .net; tokenized-by=homel .net 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

38. PRACK (I-CSCF to S-CSCF) - see example in table 17.2.2.1-38 
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I-CSCF forwards the PRACK request to S-CSCF. 

Table 17.2.2.1-38: PRACK (I-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
P-Access-Network-Inf o : 

Route: sip: scscfl .homel . net; Ir, sip: scscf2 .homel . net; Ir, sip:pcscf2 .homel . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

P-Access-Network-Info: this header contains information from the UE and will be removed and stored by the S- 
CSCF. 

39. PRACK (MO#lb to S-S) - see example in table 17.2.2.1-39 

S-CSCF forwards the PRACK request to the terminating endpoint, as per the S-CSCF to S-CSCF procedure. 

Table 17.2.2.1-39: PRACK (M0#1b to S-S) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 2 .homel . net; Ir, sip:pcscf 2 .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

40. 200 OK (S-S to MO#lb) - see example in table 17.2.2.1-40 (related to 17.2.2.1-39) 

The destination endpoint responds to the PRACK request (39) with a 200 OK response. 

Table 17.2.2.1-40: 200 OK (S-S to M0#1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

41. 200 OK (S-CSCF to I-CSCF) - see example in table 17,2,2,1-41 
S-CSCF forwards the 200 OK response to I-CSCF. 

Table 17.2.2.1-41 : 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
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Content-Length : 

42. 200 OK (I-CSCF to P-CSCF) - see example in table 17.2.2.1-42 

I-CSCF forwards the 200 OK response to P-CSCF. 

Table 17.2.2.1-42: 200 OK (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

43. 200 OK (P-CSCF to UE) - see example in table 17.2.2.1-43 
P-CSCF forwards the 200 OK response to UE. 

Table 17.2.2.1-43: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

44. 200 OK (S-S to MO#lb) - see example in table 17.2.2.1-44 (related to 17.2.2.1-8) 

When the called party answers, the terminating endpoint sends a 200 OK final response to the INVITE 
request (8), as specified by the termination procedures and the S-CSCF to S-CSCF procedures, to S-CSCF. 

Table 17.2.2.1-44: 200 OK (S-S to M0#1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .homel . net; Ir, sip: scscf 2 .homel . net; Ir, sip: scscf 1 .homel . net; Ir, 

sip : icscf l_p . homel .net;lr, sip:pcscfl. visitedl. net; Ir 

From: 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call-ID: 

CSeq: 127 INVITE 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

Content-Length: 

45. 200 OK (S-CSCF to I-CSCF) - see example in table 17.2.2.1-45 

S-CSCF sends a 200 OK final response along the signalling path back to I-CSCF. 

Table 17.2.2.1-45: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 
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46. 200 OK (I-CSCF to P-CSCF) - see example in table 17.2.2.1-46 

I-CSCF sends the 200 OK final response to P-CSCF. 

Table 17.2.2.1-46: 200 OK (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; sip;Token(sip;pcscf2. homel .net;lr, sip;scscf2. homel .net; Ir, 
sip: scscfl . homel .net; Ir ) @ homel .net; tokenized-by=homel .net, sip ; icscf l_p . homel .net, 
sip:pcscfl. visitedl. net 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

Record-Route: Header entries of the home network of the I-CSCF are tokenized. The I-CSCF itself and the UE 
addresses are not subject to tokenization. 

47. Approval of QoS Commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (13). 

48. 200 OK (P-CSCF to UE) - see example in table 17.2.2.1-48 

P-CSCF forwards the 200 OK final response to the session originator. UE can start the media flow(s) for this 
session. 

Table 17.2.2.1-48: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

49. ACK (UE to P-CSCF) - see example in table 17.2.2.1-49 

UE starts the media flow for this session, and responds to the 200 OK (48) with an ACK request sent to P- 
CSCF. 

Table 17.2.2.1-49: ACK (UE to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Networli-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To : sip : user2__publicl@home2 .net;tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfgllcj4 90333 

Cseq: 127 ACK 

Content-Length: 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in 3GPP TS 24.229 [16]. 

Cseq: Is required to be the same value as Cseq contained in original INVITE request [3]. 

50. ACK (P-CSCF to I-CSCF) - see example in table 17.2.2.1-50 
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P-CSCF adds the Route header corresponding to the session. 
P-CSCF forwards the ACK request to I-CSCF. 

Table 17.2.2.1-50: ACK (P-CSCF to I-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Inf o : 

Route: sip: icscf l_p.homel . net; Ir, sip: Token (sip: scscfl .homel . net; Ir, sip: scscf 2 .homel . net; Ir, 
sip:pcscf2 . homel . net ; Ir ) @ homel .net; tokenized-by=homel .net 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

Route: Saved from the Record-Route header of the 183 Session Progress response. 

51. ACK (I-CSCF to S-CSCF) - see example in table 17.2.2.1-51 

I-CSCF determines the routing information, and forwards the ACK request to S-CSCF. 

Table 17.2.2.1-51 : ACK (I-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
P-Access-Network-Inf o : 

Route: sip: scscf 1 .homel . net; Ir, sip: scscf2 .homel . net; Ir, sip:pcscf2 .homel . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

P-Access-Network-Info: this header contains information from the UE and will be removed and stored by the S- 
CSCF. 

52. ACK (MO#lb to S-S) - see example in table 17.2.2.1-52 

S-CSCF forwards the ACK request to the terminating endpoint, per the S-CSCF to S-CSCF procedure. 

Table 17.2.2.1-52: ACK (M0#1b to S-S) 

ACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Route: sip: scscf 2 .homel . net; Ir sip:pcscf 2 .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



17.2.2.2 Failure in termination procedure 

The roaming subscriber that initiated a session with procedure MO#lb had the attempt fail due to an error detected in 
the Termination procedure or in the S-CSCF-to-S-CSCF procedure. This could be due to, for example, destination busy 
(error code 486), destination service denied (error code 403), destination currently out of coverage (error code 480), or 
some other error. 
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Depending on the exact error that causes the session initiation failure, and when the error situation was detected, UE#1 
could be at many different stages in the session establishment procedure. This is shown in figure 17.2.2.2-1, as optional 
messages 7-43 that may appear in this error procedure. 



Visited Network 



Home Network 



UE#1 



P-CSCF 



— 1. INVITE — 
-2. 100 Trying- 



l-CSCF 
(THIG) 



-6. 100 Trying- 



13. Authorize QoS Resources 



15. PRACK > 



4 22. 200 OK 



23. Resource 
Reservation 



-24. UPDATE ^ 



4 21. 200 OK- 



25. UPDATE 1 



4 30. 200 OK- 



-35. 180 Ringing — 
36. PRACK > 



4 43. 200 OK- 



-16. PRACK ► 



-17. PRACK H 



4 20. 200 OK- 



4 — 34. 180 Ringing 



-37. PRACK - 



4 42. 200 OK- 



-47. XXX Error- 
48. ACK — 



50. Revoke QoS Resources 



-51 . XXX Error- 
52. ACK 



S-CSCF 



— 4. INVITE — 
-5. 100 Trying- 



7. Evaluation of initis 
Filter Criteria 



-8. INVITE — 
4-9. 100 Trying - 



4 10. 183- 



-18. PRACK- -► 
4—19. 200 OK 



26. UPDATE H 



4 29. 200 OK- 



-33. 180 Ringing - 



-38. PRACK - 



4 41. 200 OK- 



-46. XXX Error- 



-49. ACK- 



— 27. UPDATE -► 
4—28. 200 OK 



432. 180 Ringing- 



39. PRACK- ► 

4—40. 200 OK 



-44. XXX Error- 
45. ACK 



Figure 17.2.2.2-1: Failure in termination procedure 

1-8. INVITE (UE to P-CSCF) et seq 

UE#1 initiated a session, as described in subclause 117.2.2.1. 
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9-43.100 Trying (S-S to MO#lb) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 117.2.2.1. 

44. XXX Error (S-S to MO#lb) - see example in table 17.2.2.2-44 (related to 17.2.2.2-8) 

The termination procedure detected some error situation, and returned a SIP error response. 

NOTE 1: The error response may be, for example, "486 (Busy Here)", "403 (Service Denied)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 

Table 17.2.2.2-44: 486 Busy Here (S-S to M0#1b) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Retry-After: 3600 

Content-Length: 

45. ACK (MO#la to S-S) - see example in table 17.2.2.2-45 

Upon receive the 486 response from the S-S procedure, S-CSCF sends ACK. 

Table 17.2.2.2-45: ACK (M0#1a to S-S) 

ACK sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

46. XXX Error (S-CSCF to P-CSCF) - see example in table 17.2.2.2-46 (related to 17.2.2.2-44) 

The S-CSCF returned a SIP error response to I-CSCF. 

NOTE 2: The error response may be, for example, "486 (Busy Here)", "403 (Service Denied)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 

Table 17.2.2.2-46: 486 Busy Here (S-CSCF to I-CSCF) 

SIP/2.0 486 Busy Here 

via: SIP/2. 0/UDP icscfl„p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

47. XXX Error (1-CSCF to P-CSCF) - see example in table 17.2.2.2-47 

The I-CSCF returned a SIP error response to P-CSCF. 

NOTE 3: The error response may be, for example, "486 (Busy Here)", "403 (Service Denied)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 
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Table 17.2.2.2-47: 486 Busy Here (S-CSCF to l-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Retry-After: 3600 
Content-Length: 

48. ACK (P-CSCF to I-CSCF) - see example in table 17.2.2.2-48 

Upon receive the 486 response from the I-CSCF, P-CSCF sends ACK. 

Table 17.2.2.2-48: ACK (P-CSCF to I-CSCF) 

ACK sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Route : sip : icscf l_p . homel .net;lr, sip:Token(sip:scscfl. homel .net; Ir ) @homel .net;tokenized- 

by=homel . net 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

49. ACK (I-CSCF to S-CSCF) - see example in table 17.2.2.2-49 

Upon receive the 486 response from the P-CSCF, I-CSCF sends ACK. 

Table 17.2.2.2-49: ACK (I-CSCF to S-CSCF) 

ACK sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p. homel . net; branch=z9hG4bK351g45 . 1 

Route: sip: scscfl .homel . net; Ir 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

50. Revoke QoS authorization 

P-CSCF removes the QoS authorization, if any, for this session. 

51. XXX Error (P-CSCF to UE) - see example in table 17.2.2.2-51 (related to 17.2.2.2-47) 

The P-CSCF returned a SIP error response to UE. 

NOTE 4: The error response may be, for example, "486 (Busy Here)", "403 (Service Denied)", "480 (Temporarily 
Unavailable)", or others. For this example, "486 (Busy Here)" is shown. 



Table 17.2.2.2-51 : 486 Busy Here (P-CSCF to UE) 



SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Retry-After: 3600 

Content-Length: 



52. ACK (UE to P-CSCF) - see example in table 17.2.2.2-52 

Upon receive the 486 response from the P-CSCF, UE sends ACK. 
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Table 17.2.2.2-52: ACK (UE to P-CSCF) 

ACK sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 



17.2.2.3 Session abandoned, or resource failure 

The roaming subscriber that initiated a session with procedure MO#lb either abandoned the attempt, or was unable to 
obtain the resources necessary for the session. The signalHng flow for this error handling is shown in figure 17.2.2.3-1. 

If the session is aborted due to failure to obtain resources, it will occur at step #23 in the signalling flow; steps 24-43 
(marked as optional) will not be present. If the session is abandoned due to user command, it can happen at any point 
between steps 10-43. 
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Figure 17.2.2.3-1 : Session abandoned or resource faiiure 
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1-9. INVITE (UE to P-CSCF) et seq 

UE#1 initiated a session, as described in subclause 17.2.2.1. 

10-43. 183 SDP (S-S to MO#lb) et seq 

Session initiation possibly continued, prior to detection of a failure condition, as described in 
subclause 17.2.2.1. 

44. CANCEL (UE to P-CSCF) - see example in table 17.2.2.3-44 

The UE cancelled the original INVITE request. 

Table 17.2.2.3-44: CANCEL (UE to P-CSCF) 

CANCEL sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip : user2_publicl@home2 . net 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 CANCEL 

Content-Length: 

45. 200 OK (P-CSCF to UE) - see example in table 17.2.2.3-45 

Upon receive the CANCEL request from the UE, P-CSCF sends 200 OK. 

Table 17.2.2.3-45: 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

46. Revoke QoS authorization 

P-CSCF removes the QoS authorization, if any, for this session. 

47. CANCEL (P-CSCF to I-CSCF) - see example in table 17.2.2.3-47 (related to table 17.2.2.3-44) 

The P-CSCF forwards the CANCEL request to I-CSCF. 

Table 17.2.2.3-47: CANCEL (P-CSCF to I-CSCF) 

CANCEL user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

Route : sip : icscf l_p . homel .net;lr, sip:Token(sip:scscfl. homel .net; Ir ) @homel .net;tokenized- 

by=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

48. 200 OK (I-CSCF to P-CSCF) - see example in table 17.2.2.3-48 

Upon receiving the 200-OK response from the P-CSCF, I-CSCF sends 200 OK. 

Table 17.2.2.3-48: 200 OK (I-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1 

From: 

To: 

Call-ID: 
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CSeq: 

Content-Length: 



49. CANCEL (I-CSCF to S-CSCF) - see example in table 17.2.2.3-49 

The I-CSCF forwards the CANCEL request to S-CSCF. 

Table 17.2.2.3-49: CANCEL (I-CSCF to S-CSCF) 

CANCEL user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p.homel . net; branch=z9hG4bK351g45 . 1 

Route: sip: scscf 1 .homel . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

50. 200 OK (S-CSCF to I-CSCF) - see example in table 17.2.2.3-50 

Upon receiving the CANCEL request from the P-CSCF, S-CSCF sends 200 OK. 

Table 17.2.2.3-50: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p. homel . net;branch=z9hG4bK351g45 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

5L CANCEL (S-CSCF to S-S) - see example in table 17.2.2.3-51 (related to table 17.2.2.3-49) 

The S-CSCF forwards the CANCEL request to the appropriate S-CSCF-to-S-CSCF procedure. 

Table 17.2.2.3-51 : CANCEL (S-CSCF to S-S) 

CANCEL user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

52. 200 OK (S-S to S-CSCF) - see example in table 17.2.2.3-52 

Upon receive the CANCEL request from the S-CSCF, the next hop (whatever it is) sends 200 OK. 

Table 17.2.2.3-52: 200 OK (S-S to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

53. 487 Request Terminated (S-S to MO#lb) - see example in table 17.2.2.3-53 (related to table 17.2.2.3-8) 

The termination procedure cancelled the request, and returned a SIP error response to the original INVITE 
request. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 534 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Table 17.2.2.3-53: 487 Request Terminated (S-S to M0#1b) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Content-Length: 

54. ACK (MO#lb to S-S) - see example in table 17.2.2.3-54 

Upon receive the 487 response from the S-S procedure, S-CSCF sends ACK. 

Table 17.2.2.3-54: ACK (M0#1b to S-S) 

ACK user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

55. 487 Request Terminated (S-CSCF to I-CSCF) - see example in table 17.2.2.3-55 (related to table 17.2.2.3- 

53) 

The S-CSCF returned the SIP error response to I-CSCF. 

Table 17.2.2.3-55: 487 Request Terminated (S-CSCF to I-CSCF) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP icscfl_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

56. ACK (I-CSCF to S-CSCF) - see example in table 17.2.2.3-56 

Upon receive the ACK from the P-CSCF, I-CSCF sends ACK. 

Table 17.2.2.3-56: ACK (I-CSCF to S-CSCF) 

ACK sip:scscfl. homel. net SIP/2.0 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

57. 487 Request Terminated (I-CSCF to P-CSCF) - see example in table 17.2.2.3-57 
The I-CSCF returned the SIP error response to P-CSCF. 

Table 17.2.2.3-57: 487 Request Terminated (I-CSCF to P-CSCF) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
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Call-ID: 

CSeq: 

Content-Length: 



58. ACK (P-CSCF to I-CSCF) - see example in table 17.2.2.3-58 

Upon receive the 487 response from the S-CSCF, P-CSCF sends ACK. 

Table 17.2.2.3-58: ACK (P-CSCF to I-CSCF) 

ACK sip:icscfl_p. homel.net SIP/2. OVia: SIP/2. 0/UDP pcscfl.visitedl.net 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

59. 487 Request Terminated (P-CSCF to UE) - see example in table 17.2.2.3-59 (related to table 17.2.2.3-56) 

The P-CSCF returned a SIP error response to UE. 

Table 17.2.2.3-59: 487 Request Terminated (P-CSCF to UE) 

SIP/2.0 487 Request Terminated 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

60. ACK (UE to P-CSCF) - see example in table 17.2.2.3-60 

Upon receive the 487 response from the P-CSCF, UE sends ACK. 

Table 17.2.2.3-60: ACK (UE to P-CSCF) 

ACK sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 127 ACK 

Content-Length: 

1 7.3 S-CSCF (MGCF) to S-CSCF (MGCF) procedures 

17.3.1 Introduction 

See subclause 7.3.1. 

17.3.2 S-S#1b 

1 7.3.2.1 (S-S#1 b) Different network operators performing origination and termination, 

with configuration hiding by both network operators (M0#2, MT#2 assumed) 

Figure 17.3.2.1-1 shows a S-CSCF handling session origination (S-CSCF#1) which performs an analysis of the 
destination address, and determines that it belongs to a subscriber of a different operator. The originating network 
operator desires to keep their configuration hidden, so forwards the request through an I-CSCF (I-CSCF#1) to a 
well-known entry point in the destination operator's network, I-CSCF#2. 1-CSCF#2 queries the HSS for current location 
information, and finds the S-CSCF assigned to the subscriber (S-CSCF#2), and forwards the request to S-CSCF#2. The 
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terminating network operator also desires to keep their configuration hidden, so I-CSCF#2 inserts itself into the 
signalling path for future exchanges. 

Origination sequences that share this common S-CSCF to S-CSCF procedure are: 

MO#la Mobile origination, roaming, without a THIG. The "Originating Network" of S-S#lb is therefore a 

visited network. 

MO#lb Mobile origination, roaming, with a THIG in home network. The "Originating Network" of S- 

S#lb is therefore a visited network. 

MO#2 Mobile origination, located in home service area. The "Originating Network" of S-S#lb is 

therefore the home network. 

CS-O CS Networks origination. The "Originating Network" of S-S#lb is the home network. The element 

labelled S-CSCF#1 is the MGCF of the CS-O procedure. 

Termination sequences that share this common S-CSCF to S-CSCF procedure are: 

MT#la Mobile termination, roaming, without a THIG. The "Terminating Network" of S-S#lb is a visited 

network. 

MT#lb Mobile termination, roaming, with a THIG in home network. The "Terminating Network" of 

S-S#lb is a visited network. 

MT#2 Mobile termination, located in home service area. The "Terminating Network" of S-S#lb is the 

home network. 
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Figure 17.3.2.1-1: S-S#1b 

Procedure S-S#lb is as follows: 

1 . INVITE (MO to S-S#lb) - see example in table 17.3.2,1-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 17.3.2.1-1 : INVITE (MO to S-S#1b) 

INVITE sip:user2_publicl@homel.net SIP/2.0 
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Via: SIP/2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 

Record-Route ; sip;pcscfl. homel .net; Ir 
Route; sip; scscfl .homel . net; Ir 

Remote-Party-ID; "John Doe" <sip ; userl_publicl@homel . net> 
RPID-Privacy ; privacy=of f ; party=calling 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
From; sip ; userl_publicl@homel . net ; tag=171828 
To; sip ; user2_publicl@home2 . net 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 127 INVITE 
Require; precondition 
Supported; lOOrel 

Contact; sip; [5555; ; aaa ; bbb ; ccc ; ddd] 
Content-Type; application/sdp 
Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap ; 9 9 ; MP V 

m=video 3402 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap; 99;MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

2. 100 Trying (S-S#lb to MO) - see example in table 17.3.2.1-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 17.3.2.1-2: 100 Trying (S-S#1b to MO) 

SIP/2.0 100 Trying 

Via; SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To; 

Call-ID; 
CSeq; 
Content-Length; 

3 . Evaluation of initial filter criterias 
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S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For this 
example, assume no Application Server involvement. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 17.3.2.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator desires to keep their internal configuration 
hidden, S-CSCF#1 forwards the INVITE request to I-CSCF#1 adding I-CSCF#1 to the top of the Route 
Header. 

S-CSCF examines the media parameters, and removes any choices that the subscriber does not have authority 
to request. For this example, assume the subscriber is not allowed video. 

Table 17.3.2.1-4: INVITE (S-CSCF to I-CSCF) 

INVITE sip:user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel .net ; Ir 

Route: sip: icscfl_s .homel . net; Ir, sip: icscf2_s ,home2 , net; Ir 

Remote-Party-ID: "John Doe" <sip : userl_publicl@homel . net>; screen=yes 

RPID-Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

C=IN IP6 5555: : aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



ETSI 



3GPP TS 24.228 version 5.3.0 Release 5 540 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Request-URI: In the case of a TEL-URL, it has to be translated to a globally routable SIP-URL before sending 
the INVITE request. For this address translation the S-CSCF may use the services of an ENUM- 
DNS based database structure, or any other suitable translation database. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 

Route: Updated to cause I-CSCF to forward the request to an I-CSCF in the terminating operator's 

network. The topmost Route header is set to the I-CSCF (THIG) for configuration hiding. 

5. INVITE (I-CSCF to I-CSCF) - see example in table 17.3.2.1-5 

I-CSCF#1 forwards the INVITE request to I-CSCF#2 using the topmost route header. 

Table 17.3.2.1-5: INVITE (I-CSCF to I-CSCF) 

INVITE sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s . homel . net ;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards : 67 

Record-Route : sip : icscf l_s . homel .net;lr, sip:Token(sip:scscfl. homel .net; Ir, 
sip:pcscfl . homel .net; Ir ) @ homel .net; tokenized-by=homel .net 
Route: sip: icscf2_s .home2 . net; Ir 
Remote-Party-ID : 
RPID-Privacy : 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 
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Via:/Record-Route: I-CSCF#1 Encrypts all the entries that belong to its own network to maintain configuration 
independence of the home#l operator. 

6. 100 Trying (I-CSCF to I-CSCF) - see example in table 17.3.2.1-6 

I-CSCF#2 respond to the INVITE request (5) with a 100 Trying provisional response. 

Table 17.3.2.1-6: 100 Trying (I-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf l_s . homel . net ;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

7. 100 Trying (I-CSCF to S-CSCF) - see example in table 17.3.2.1-7 

I-CSCF#1 decrypts the Via header entries that are tokenised and belong to its own network, and forwards the 
100 Trying provisional response to S-CSCF#1. 



Table 17.3.2.1-7: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

8. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [11]. 

Table 7.3.2-6a provides the parameters in the SIP INVITE request (flow 5) which are sent to the HSS. 

Table 7.3.2-6b provides the parameters sent from the HSS that need to be mapped to the SIP INVITE request 
(flow 9) and sent to the S-CSCF. 

9. INVITE (I-CSCF to S-CSCF) - see example in table 17.3.2.1-9 

I-CSCF#2 forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 17.3.2.1-9: INVITE (I-CSCF to S-CSCF) 

INVITE sip:user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscfl .homel . net; branch=z9hG4bK4 31h23 . 1) @homel . net; tokenized-by=homel . net, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Record-Route : sip : icscf 2_s . home 2 .net;lr, sip:312a32. K^icscf l_s . homel .net; Ir, 

sip: Token (sip: scscfl .homel . net; Ir, sip:pcscfl .homel . net; Ir) ghomel . net; tokenized-by=homel . net 
Route: sip: scscf 2 .home2 . net; Ir 
Remote-Party-ID : 
RPID-Privacy : 
P-Charging-Vector : 
From: 
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To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 



10. 100 Trying (S-CSCF to I-CSCF) - see example in table 17.3.2.1-10 

S-CSCF#2 responds to the INVITE request (9) with a 100 Trying provisional response. 

Table 17.3.2.1-10: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



1 1. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. 

12. INVITE (S-S#lb to MT) - see example in table 17.3.2.1-12 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. 
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Table 17.3.2.1-12: INVITE (S-S#1b to MT) 

INVITE sip:user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; token! zed-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards ; 65 

Record-Route; sip: scscf 2 .home2 . net; Ir, sip : icscf 2_s . home2 . net ; Ir, sip : icscf l_s . homel . net ; Ir, 
sip: Token (sip: scscfl . homel . net; Ir, sip:pcscfl . homel .net; Ir ) (3 homel .net; tokenized-by=homel .net 
Route: sip:pcscf2 .home2 . net; Ir 
Remote-Party-ID : 
RPID-Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 

P-Called-Party-ID: <sip: user2_publicl(3home2 . net> 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

13. 100 Trying (MT to S-S#lb) - see example in table 17.3.2.1-13 

S-CSCF#2 receives a 100 Trying provisional response to the INVITE request (12), as specified by the 
termination procedures. 



Table 17.3.2.1-13: 100 Trying (MT to S-S#1b) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 

SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
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pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/2.0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

14. 183 Session Progress (MT to S-S#lb) - see example in table 17.3.2.1-14 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response to the INVITE request (12), as per the termination procedure. 

Table 17.3.2.1-14: 183 Session Progress (MT to S-S#1b) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip : icscf l_s . homel .net; Ir, 

sip: Token (sip: scscfl . homel . net; Ir, sip:pcscfl . homel .net; Ir ) (? homel .net; tokenized-by=homel .net 
Remote-Party-ID: "John Smith" <sip:user2_publicl(3home2 . net> 
RPID-Privacy : privacy=of f ; party=called 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 

To: sip : user2_publicl(3home2 . net ; tag=314159 
Call-ID: 
CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

15. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 17,3.2,1-15 

S-CSCF#2 forwards the 183 Session Progress provisional response to 1-CSCF#2. 

Table 17.3.2.1-15: 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2„s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 

Remote-Party-ID: "John Smith" <sip:user2_publicl(3home2 . net>; screen=yes 
RPID-Privacy: 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
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P-Charging-Funct ion-Addresses: ccf=[5555: :b99 : c88 : d77 : e66] ; ccf=[5555: : a55 :b4 4 : c33 : d22] ; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc: 9ddl 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



P-Charging- Vector: The S-CSCF adds the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 

16. 183 Session Progress (I-CSCF to I-CSCF) - see example in table 17.3.2.1-16 

I-CSCF#2 forwards the 183 Session Progress provisional response to I-CSCF#1. 

Table 17.3.2.1-16: 183 Session Progress (I-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : sip:Token(sip:pcscf2. home 2 . net; Ir, sip : scscf2 . home 2 .net; Ir ) @ home 2 .net;tokenized- 
by=home2 .net, sip : icscf 2_s . home 2 .net;lr, sip: icscf l_s . homel .net; Ir, 

sip: Token (sip: scscfl . homel . net; Ir, sip:pcscfl . homel .net; Ir ) (3 homel .net; tokenized-by=homel .net 
Remote-Party-ID : 
RPID-Privacy : 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
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Record-Route: The I-CSCF#2 encrypts all the entries belonging to its own network (home#2). 
17. 183 Session Progress (I-CSCF to S-CSCF) - see example in table 17,3.2,1-17 

I-CSCF#1 forwards the 183 Session Progress provisional response to S-CSCF#1. 

Table 17.3.2.1-17: 183 Session Progress (I-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : sip:Token(sip:pcscf2. home 2 .net;lr, sip:scscf2. home 2 .net; Ir ) @ home 2 .net;tokenized- 

by=home2 . net , sip: icscf 2_s .home2 . net; Ir, sip: icscfl_s .homel . net; Ir, sip: 

Token {sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir ) @ homel .net; tokenized-by=homel .net 

Remote-Party-ID : 

RPID-Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



Via/Record-Route: I-CSCF#1 decrypts all the entries that are tokenised and belong to its own network. 
18. 183 Session Progress (S-S#lb to MO) - see example in table 17.3.2.1-18 

S-CSCF#1 forwards the 183 Session Progress to the originator, as per the originating procedure. 

Table 17.3.2.1-18: 183 Session Progress (S-S#1b to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscfl .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
Remote-Party-ID : 
RPID-Privacy: 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
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Contact : 
RSeq: 

Content-Type : 
Content-Length : 



19. PRACK (MO to S-S#lb) - see example in table 17.3.2.1-19 

The originator decides the final set of media streams, and includes this information in the PRACK request 
sent to S-CSCF#1 by the origination procedures. 

Table 17.3.2.1-19: PRACK (MO to S-S#1b) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscfl_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip: Token (sip: scscf2 . home 2 .net;lr, sip:pcscf2. home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: sip : userl_publicl@homel . net ; tag=171828 
To : sip: user 2_publicl@home2 . net; tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 128 PRACK 
Require: precondition 
Rack: 9021 127 INVITE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

20. PRACK (S-CSCF to I-CSCF) - see example in table 17.3.2.1-20 

S-CSCF#1 forwards the PRACK request to 1-CSCF#1. 

Table 17.3.2.1-20: PRACK (S-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 
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Route : sip: icscf l_s .homel . net; Ir, sip: icscf 2_s .home 2 . net; Ir, sip: Token (sip:scscf2 .home 2 . net; Ir, 

sip:pcscf2 . home 2 .net; Ir ) @ home 2 .net; tokenizecl-by=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



21. PRACK (I-CSCF to I-CSCF) - see example in table 17.3.2.1-21 

I-CSCF#1 forwards the PRACK request to I-CSCF#2. 

Table 17.3.2.1-21 : PRACK (I-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route : sip : icscf 2_s . home 2 .net;lr, sip:Token(sip:scscf2. home 2 .net; Ir, 
sip:pcscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



Via: I-CSCF#1 encrypts all the entries that belong to its own network to maintain 

configuration independence of the home#l operator. 

22. PRACK (I-CSCF to S-CSCF) - see example in table 17.3.2.1-22 
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I-CSCF#2 decrypts all the tokenized route entries belonging to its own network to recover the routing 
information, and forwards the PRACK request to S-CSCF#2. 

Table 17.3.2.1-22: PRACK (l-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route: sip: scscf2 .home2 . net; Ir, sip:pcscf2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c = 

t = 



23. PRACK (S-S#lb to MT) - see example in table 17.3.2.1-23 

S-CSCF#2 forwards the PRACK request to the terminating endpoint, as per the termination procedure. 

Table 17.3.2.1-23: PRACK (S-S#1b to MT) 



PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . home 1 . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 
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24. 200 OK (MT to S-S#lb) - see example in table 17.3.2.1-24 

The terminating endpoint responds to the PRACK request (23) with a 200 OK response. 

Table 17.3.2.1-24: 200 OK (MT to S-S#1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . 
SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1) Shomel . net; tokenized-by=homel . 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 



net;branch=z9hG4bK312a32. 1, 

SIP/2. 0/UDP 
net, SIP/2. 0/UDP 



v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



25. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.2.1-25 

S-CSCF#2 forwards the 200 OK response to I-CSCF#2. 



Table 17.3.2.1-25: 200 OK (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1) Shomel . net; tokenized-by=homel . net, 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 

CSeq: Content-Type: 
Content-Length : 



SIP/2. 0/UDP 
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26. 200 OK (I-CSCF to I-CSCF) - see example in table 17.3.2.1-26 

I-CSCF#2 forwards the 200 OK response to I-CSCF#1. 

Table 17.3.2.1-26: 200 OK (I-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; token! zed-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



27. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.2.1-27 

I-CSCF#1 forwards the 200 OK response to S-CSCF#1. 

Table 17.3.2.1-27: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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Via: I-CSCF#1 decrypts all the tokenised entries belonging to its own network. 

28. 200 OK (S-S#lb to MO) - see example in table 17.3.2.1-28 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 17.3.2.1-28: 200 OK (S-S#1b to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



29. UPDATE (MO to S-S#lb) - see example in table 17.3.2.1-29 

When the originating endpoint has completed the resource reservation procedures, it sends the UPDATE 
request to S-CSCF#1 by the origination procedures. 

Table 17.3.2.1-29: UPDATE (MO to S-S#1b) 

UPDATE sip: [5555: : eee : f f f : aaa : bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscfl_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip: Token (sip: scscf2 . home 2 .net;lr, sip:pcscf2. home 2 .net; Ir ) @ home 2 . net ; tokenized-by=home2 .net 
From: sip : userl_publicl@homel . net ; tag=171828 
To : sip : user2_publicl@home2 .net;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 129 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 
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30. UPDATE (S-CSCF to I-CSCF) - see example in table 17.3.2.1-30 

S-CSCF#1 forwards the UPDATE request to I-CSCF#1. 

Table 17.3.2.1-30: UPDATE (S-CSCF to I-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : sip : icscf l_s . homel .net;lr, sip: icscf 2_s . home 2 .net;lr, sip:Token(sip:scscf2. home 2 .net; Ir, 

sip:pcscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



31. UPDATE (I-CSCF to I-CSCF) - see example in table 17.3.2.1-31 

I-CSCF#1 forwards the UPDATE request to I-CSCF#2. 

Table 17.3.2.1-31 : UPDATE (I-CSCF to I-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l„s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route : sip : icscf 2_s . home 2 .net;lr, sip:Token(sip:scscf2. home 2 .net; Ir, 
sip:pcscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 
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Via:: I-CSCF#1 encrypts all the entries belonging to its own network to maintain 

configuration independence of the home#l operator. 

32. UPDATE (I-CSCF to S-CSCF) - see example in table 17.3.2.1-32 

I-CSCF#2 decrypts all the tokenised Route entries belonging to its own network and forwards the UPDATE 
request to S-CSCF#2. 

Table 17.3.2.1-32: UPDATE (I-CSCF to S-CSCF) 

UPDATE sip: [5555: : eee : f f f : aaa : bbb] SIP/ 2.0 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route: sip: scscf2 .home2 . net; Ir, sip:pcscf2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



33. UPDATE (S-S#lb to MT) - see example in table 17.3.2.1-33 

S-CSCF#2 forwards the UPDATE request to the terminating endpoint, as per the termination procedure. 

Table 17.3.2.1-33: UPDATE (S-S#1b to MT) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c = 

t = 
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34. 200 OK (MT to S-S#lb) - see example in table 17.3.2.1-34 

The terminating endpoint responds to the UPDATE request (33) with a 200 OK response. 

Table 17.3.2.1-34: 200 OK (MT to S-S#1b) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . 
SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1) Shomel . net; tokenized-by=homel . 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



35. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.2.1-35 

S-CSCF#2 forwards the 200 OK response to I-CSCF#2. 



net;branch=z9hG4bK312a32. 1, 

SIP/2. 0/UDP 
net, SIP/2. 0/UDP 



Table 17.3.2.1-35: 200 OK (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s. homel. net ;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscf 1 . homel .net; branch=z9hG4bK431h23 . 1 ) (§ homel .net; tokenized-by=homel .net, 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



SIP/2. 0/UDP 
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36. 200 OK (I-CSCF to I-CSCF) - see example in table 17.3.2.1-36 

I-CSCF#2 forwards the 200 OK response to I-CSCF#1. 

Table 17.3.2.1-36: 200 OK (I-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net; token! zed-by=homel . net, SIP/ 2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



37. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.2.1-37 

I-CSCF#1 forwards the 200 OK response to S-CSCF#1. 

Table 17.3.2.1-37: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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Via: I-CSCF#1 decrypts all the tokenisedentries belonging to its own network. 

38. 200 OK (S-S#lb to MO) - see example in table 17.3.2.1-38 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 17.3.2.1-38: 200 OK (S-S#1b to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



39. 180 Ringing (MT to S-S#lb) - see example in table 17.3.2.1-39 

The terminating endpoint may optionally send a 180 Ringing provisional response indicating alerting is in 
progress. This response is sent by the termination procedure to S-CSCF#2. 

Table 17.3.2.1-39: 180 Ringing (MT to S-S#1b) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscfl_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, S IP /2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip : icscf l_s . homel .net;lr, sip:Token(sip:scscfl. homel . net ; Ir, 
sip:pcscfl . homel .net; Ir ) @ homel .net; tokenized-by=homel .net 
From: 
To: 

Call-ID: 
CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 
RSeq: 9022 
Content-Length: 

40. 180 Ringing (S-CSCF to I-CSCF) - see example in table 17.3.2.1-40 

S-CSCF#2 forwards the 180 Ringing response to I-CSCF#2. 

Table 17.3.2.1-40: 180 Ringing (S-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net; tokenized-by=homel . net, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact: RSeq: 

Content-Length : 



41. 180 Ringing (I-CSCF to I-CSCF) - see example in table 17.3.2.1-41 

I-CSCF#2 forwards the 180 Ringing response to I-CSCF#1. 

Table 17.3.2.1-41: 180 Ringing (I-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : sip: Token (sip:pcscf2 . home 2 .net;lr, sip:scscf2. home 2 .net; Ir) @ home 2 .net;tokenized- 
by=home2 .net, sip : icscf 2_s . home 2 .net;lr, sip: icscf l_s . homel .net; Ir, 

sip: Token (sip: scscfl . homel . net; Ir, sip:pcscfl . homel .net; Ir) (? homel .net; tokenized-by=homel .net 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

Record-Route: I-CSCF#2 encrypts allthe entries belonging to its own network. 
42. 180 Ringing (I-CSCF to S-CSCF) - see example in table 17.3.2.1-42 

I-CSCF#1 forwards the 180 Ringing response to S-CSCF#1. 



Table 17.3.2.1-42: 180 Ringing (I-CSCF to S-CSCF) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route : sip:Token(sip:pcscf2. home 2 .net;lr, sip:scscf2. home 2 . net ; Ir ) (3home2 .net;tokenized- 

by=home2 . net , sip: icscf 2_s .home2 . net; Ir, sip: icscf l_s .homel . net; Ir, sip: scscf 1 .homel . net; Ir, 

sip:pcscfl . homel .net; Ir 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

Record-Route: I-CSCF#1 decrypts all the entries belonging to its own network. 

Via: I-CSCF#1 decrypts all the tokenised entries belonging to its own network. 

43. 180 Ringing (S-S#lb to MO) - see example in table 17.3.2.1-43 

S-CSCF#1 forwards the 180 Ringing response to the originator, per the origination procedure. 

Table 17.3.2.1-43: 180 Ringing (S-S#1b to MO) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscfl .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 
Call-ID: 
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CSeq: 
Require : 
Contact : 
RSeq: 

Content-Length : 



44. PRACK (MO to S-S#lb) - see example in table 17.3.2.1-44 

The originator acknowledges the 180 Ringing provisional response (43) with a PRACK request. 

Table 17.3.2.1-44: PRACK (MO to S-S#1b) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscfl_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip: Token (sip: scscf2 . home 2 .net;lr, sip:pcscf2. home 2 . net ; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: sip : userl_publicl@homel . net ; tag=171828 
To : sip : user2_publicl@home2 .net;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 

45. PRACK (S-CSCF to I-CSCF) - see example in table 17.3.2.1-45 

S-CSCF#1 forwards the PRACK request to I-CSCF#1. 

Table 17.3.2.1-45: PRACK (S-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : sip : icscf l_s . homel .net; Ir, sip: icscf 2_s . home 2 . net; Ir, sip: Token (sip: scscf2 . home 2 .net; Ir, 

sip:pcscf2 . home 2 .net; Ir ) (§home2 .net; tokenized-by=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

46. PRACK (I-CSCF to I-CSCF) - see example in table 17.3.2.1-46 

I-CSCF#1 forwards the PRACK request to I-CSCF#2. 



Table 17.3.2.1-46: PRACK (I-CSCF to I-CSCF) 



PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) (ahomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route : sip : icscf 2_s . home 2 .net;lr, sip:Token(sip:scscf2. home 2 .net; Ir, 
sip:pcscf2 . home 2 .net; Ir ) (3home2 .net; tokenized-by=home2 .net 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 



Via: 



I-CSCF#1 encrypts all the entries belonging to its own network maintain 
configuration independence of the home#l operator. 



47. PRACK (I-CSCF to S-CSCF) - see example in table 17.3.2.1-47 
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I-CSCF#2 determines the routing information, and forwards the PRACK request to S-CSCF#2. 
Table 17.3.2.1-47: PRACK (l-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

48. PRACK (S-S#lb to MT) - see example in table 17.3.2.1-48 

S-CSCF#2 forwards the PRACK request to the terminating endpoint. 

Table 17.3.2.1-48: PRACK (S-S#1b to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2„s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . home 1 . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) (ahomel . net ; tokenized-by=homel . net , SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 

Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

49. 200 OK (MT to S-S#lb) - see example in table 17.3.2.1-49 

The terminating endpoint responds to the PRACK request (48) with a 200 OK response. 

Table 17.3.2.1-49: 200 OK (MT to S-S#1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ;branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

50. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.2.1-50 

S-CSCF#2 forwards the 200 OK response to I-CSCF#2. 

Table 17.3.2.1-50: 200 OK (S-CSCF to l-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) (ahomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



51. 200 OK (I-CSCF to I-CSCF) - see example in table 17.3.2.1-51 

I-CSCF#2 forwards the 200 OK response to I-CSCF#1. 

Table 17.3.2.1-51 : 200 OK (I-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

52. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.2.1-52 

I-CSCF#1 forwards the 200 OK response to S-CSCF#1. 

Table 17.3.2.1-52: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

Via: I-CSCF#1 decrypts all tokenised entries that belong to its network.. 

53. 200 OK (S-S#lb to MO) - see example in table 17.3.2.1-53 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 17.3.2.1-53: 200 OK (S-S#1b to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

54. 200 OK (MT to S-S#lb) - see example in table 17.3.2.1-54 

The final response to the INVITE (12), 200 OK, is sent by the terminating endpoint over the signalling path. 
This is typically generated when the subscriber has accepted the incoming session attempt. The response is 
sent to S-CSCF#2 per the termination procedure. 

Table 17.3.2.1-54: 200 OK (MT to S-S#1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1, SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK3 12a3 2 . 1, 

SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
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pcscfl.homel.net;branch=z9hG4bK431h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/2.0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route; sip;pcscf 2 .home2 . net; Ir, sip; scscf 2 .home2 . net; Ir, sip; icscf 2_s .home2 . net; Ir, 
sip ; icscf l_s . homel .net;lr, sip;Token(sip;scscfl. homel .net; Ir, 
sip;pcscfl . homel .net; Ir ) @ homel .net; tokenized-by=homel .net 
From; 
To; 

Call-ID; 

CSeq; 127 INVITE 

Contact; sip; [5555; ; eee ; f f f ; aaa;bbb] 
Content-Length; 



55. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.2.1-55 

The 200 OK response is forwarded to the I-CSCF#2. 



Table 17.3.2.1-55: 200 OK (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via; SIP/2. 0/UDP icscf2_s .home2 .net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 ; ; aaa; bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route ; 
From; 
To; 

Call-ID; 
CSeq; 
Contact ; 
Content-Length ; 



56. 200 OK (I-CSCF to I-CSCF) - see example in table 17.3.2.1-56 

The 200 OK response is forwarded to I-CSCF#1. 

Table 17.3.2.1-56: 200 OK (I-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP icscf l_s .homel .net;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 ; ; aaa; bbb; ccc ; ddd] ;branch=z9hG4bKnashds7 
Record-Route ; sip;Token(sip;pcscf2. home 2 .net, sip;scscf2. home 2 . net ) (3 home 2 .net;tokenized- 



by=home2 . net , sip; icscf 2_s .home2 . net, sip;icscfl 

sip;pcscfl . homel . net ) (? homel .net; tokenized-by=homel .net 

From; 

To; 

Call-ID; 

CSeq; 

Contact : 

Content-Length ; 



homel .net, sip;Token(sip;scscfl. homel .net. 



Record-Route: I-CSCF#2 encrypts all the entries that belong to its network. 
57. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.2.1-57 

The 200 OK response is forwarded to S-CSCF#1. 



Table 17.3.2.1-57: 200 OK (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via; SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, 



SIP/2. 0/UDP 



pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route ; sip;Token(sip;pcscf2. home 2 .net;lr, sip;scscf2. home 2 .net; Ir ) @ home 2 .net;tokenized- 



by=home2 .net, sip ; icscf 2_s . home 2 .net; Ir, 

sip;pcscfl . homel .net; Ir 

From; 

To; 

Call-ID; 

CSeq; 



sip ; icscf l_s . homel .net;lr, sip;scscfl. homel .net; Ir, 
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Contact : 
Content-Length ; 



Record-Route: I-CSCF#1 decrypts all the tokenised entries belonging to its own network. 
Via: I-CSCF#1 decrypts all the tokenised entries that belong to its own network. 

58. 200 OK (S-S#lb to MO) - see example in table 17.3.2.1-58 

The 200 OK response is returned to the originating endpoint, by the origination procedure. 

Table 17.3.2.1-58: 200 OK (S-S#1b to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

59. ACK (MO to S-S#lb) - see example in table 17.3.2.1-59 

The originating endpoint sends the final acknowledgement to S-CSCF#1 by the origination procedures. 

Table 17.3.2.1-59: ACK (MO to S-S#1b) 

ACK sip: [5555: : eee : f f f : aaa : bbb] SIP/ 2. 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branc]i=z9]iG4bKnas]ids7 
Max-Forwards: 69 

Route : sip:scscfl. liomel . net; Ir, sip : icscf l_s . liomel . net; Ir, sip : icscf 2_s . ]iome2 . net; Ir, 
sip : To Ice n (sip : scscf 2 . ]iome2 . net; Ir, sip : pcscf 2 . ]iome2 . net ; Ir ) @]iome2 . net; to]<:enized-by=]iome2 . net 
From: sip : userl_publicl@]iomel . net; tag=171828 
To : sip : user2_publicl@]iome2 . net; tag=31415 9 
Call- ID: cb03a0s0 9a2sdfgl]cj4 90333 
Cseq: 127 ACK 
Content-Lengtli : 

60. ACK (S-CSCF to I-CSCF) - see example in table 17.3.2.1-60 

S-CSCF#1 forwards the ACK request to I-CSCF#1. 

Table 17.3.2.1-60: ACK (S-CSCF to I-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : sip : icscf l_s . homel .net;lr, sip: icscf 2_s . home 2 .net;lr, sip:Token(sip:scscf2. home 2 .net; Ir, 

sip:pcscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

61. ACK (I-CSCF to I-CSCF) - see example in table 17.3.2.1-61 

I-CSCF#1 forwards the ACK request to I-CSCF#2. 

Table 17.3.2.1-61 : ACK (I-CSCF to I-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP icscf l_s .homel .net;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; token! zed-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards ; 67 

Route ; sip ; icscf 2_s . home 2 .net;lr, sip;Token(sip;scscf2. home 2 .net; Ir, 
sip:pcscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

Via:: I-CSCF#1 encrypts all the entries that belong to its own network to maintain 

configuration independence of the home#l operator. 

62. ACK (I-CSCF to S-CSCF) - see example in table 17.3.2.1-62 

I-CSCF#2 decrypts all the tokenised Route entries that belong to its own network and forwards the ACK 
request to S-CSCF#2. 

Table 17.3.2.1-62: ACK (I-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pes cfl. homel. net ;branch=z9hG4bK4 31h2 3.1) ghomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route: sip: scscf2 .home2 . net; Ir, sip:pcscf2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

63. ACK (S-S#lb to MT) - see example in table 17.3.2.1-63 

S-CSCF#2 forwards the ACK request to the terminating endpoint, as per the termination procedure. 

Table 17.3.2.1-63: ACK (S-S#1b to MT) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



17.3.2.2 Termination failure (not provided) 

An example of this flow is not shown in the present document. 

17.3.2.3 Origination failure (not provided) 

An example of this flow is not shown in the present document. 

17.3.3 S-S#1c 
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1 7.3.3.1 (S-S#1 c) Different network operators performing origination and termination, 

with configuration hiding by originating network operator (M0#2, MT#2 
assumed) 

Figure 17.3.3.1-1 shows a S-CSCF handling session origination (S-CSCF#1) which performs an analysis of the 
destination address, and determines that it belongs to a subscriber of a different operator. The originating network 
operator desires to keep their configuration hidden, so forwards the request through an 1-CSCF (1-CSCF#1) to a 
well-known entry point in the destination operator's network, 1-CSCF#2. 1-CSCF#2 queries the HSS for current location 
information, and finds the S-CSCF assigned to the subscriber (S-CSCF#2), and forwards the request to S-CSCF#2. The 
terminating network operator does not desire to keep their configuration hidden, so 1-CSCF#2 does not insert itself into 
the signalling path for future exchanges. 

Origination sequences that share this common S-CSCF to S-CSCF procedure are: 

MO#la Mobile origination, roaming, without a THIG. The "Originating Network" of S-S#lc is therefore a 

visited network. 

MO#lb Mobile origination, roaming, with a THIG in home network. The "Originating Network" of S- 

S#lc is therefore a visited network. 

MO#2 Mobile origination, located in home service area. The "Originating Network" of S-S#lc is 

therefore the home network. 

CS-O CS Networks origination. The "Originating Network" of S-S#lc is the home network. The element 

labeled S-CSCF#1 is the MGCF of the CS-O procedure. 

Termination sequences that share this common S-CSCF to S-CSCF procedure are: 

MT#la Mobile termination, roaming, without a THIG. The "Terminating Network" of S-S#lc is a visited 

network. 

MT#lb Mobile termination, roaming, with a THIG in home network. The "Terminating Network" of S- 

S#lc is a visited network. 

MT#2 Mobile termination, located in home service area. The "Terminating Network" of S-S#lc is the 

home network. 
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Figure 17.3.3.1-1: S-S#1c 

Procedure S-S#lc is as follows: 

1 . INVITE (MO to S-S#lc) - see example in table 17.3.3.1-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 

Table 17.3.3.1-1 : INVITE (MO to S-S#1c) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 
Route; sip; scscfl .homel . net; Ir 
Record-Route ; sip;pcscfl. homel .net; Ir 

P-Asserted-Identity ; "John Doe" <sip;userl_publicl@homel . net> 
Privacy; none 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
From; sip ; userl_publicl@homel . net ; tag=171828 
To; sip ; user2_publicl@home2 . net 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 127 INVITE 
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Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa : bbb : ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video 3400 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video 34 02 RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 



2. 100 Trying (S-S#lc to MO) - see example in table 17.3.3.1-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 17.3.3.1-2: 100 Trying (S-S#1c to MO) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

3. Evaluation of Filter Criteria 

S-CSCF#1 validates the service profile of this subscriber, and evaluates the initial filter criterias. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 17.3.3.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator desires to keep their internal configuration 
hidden, S-CSCF#1 forwards the INVITE request to I-CSCF#1. 



Table 17.3.3.1-4: INVITE (S-CSCF to I-CSCF) 



INVITE sip: user2_publicl@home2.net SIP/2.0 
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Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: icscfl_s .homel . net; Ir 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 

Privacy: none 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Required: 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

Route: Topmost Route header set to the I-CSCF that will perform the translation needed to maintain 

configuration independence. 

SDP The SDP contains the restricted set of codecs allowed by the network operator. The "m=" lines for 

the second audio stream shows a port number zero, which removes it from the negotiation. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 



5. INVITE (I-CSCF to I-CSCF) - see example in table 17.3.3.1-5 

I-CSCF#1 forwards the INVITE request to I-CSCF#2. 
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Table 17.3.3.1-5: INVITE (l-CSCF to l-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, SIP/ 2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1) @homel . net ; tokenized- 
by=homel . net , SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 67 

Record-Route : sip : icscf l_s . homel .net;lr, sip:Token(sip:scscfl. homel .net; Ir, 
sip:pcscfl . homel .net; Ir ) @ homel .net; tokenized-by=homel .net 
P-Asserted- Identity : 
Privacy : 

P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 



Via:/Record-Route: Translated to maintain configuration independence of the home#l operator. 
6. 100 Trying (I-CSCF to I-CSCF) - see example in table 17.3.3.1-6 

I-CSCF#2 respond to the INVITE request (5) with a 100 Trying provisional response. 

Table 17.3.3.1-6: 100 Trying (l-CSCF to l-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1) @homel . net ; tokenized- 
by=homel . net , S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
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To: 

Call-ID: 

CSeq: 

Content-Length: 



7. 100 Trying (I-CSCF to S-CSCF) - see example in table 17.3.3.1-7 

I-CSCF#1 determines the Via header, and forwards the 100 Trying provisional response to S-CSCF#1. 

Table 17.3.3.1-7: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

8. Cx: User Location Query procedure 

The 1-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228. 

Table 7.3.2-6a provides the parameters in the SIP INVITE request (flow 5), which are sent to the HSS. 

Table 7.3.2-6b provides the parameters sent from the HSS that are mapped to the SIP INVITE request 
(flow 9) and sent to the S-CSCF. 

9. INVITE (I-CSCF to S-CSCF) - see example in table 17.3.3.1-9 

I-CSCF#2 forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 17.3.3.1-9: INVITE (I-CSCF to S-CSCF) 

INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf2„s . homel . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

icscfl_s. homel. net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: && 
Route: sip: scscf 2 .home2 . net; Ir 
Record-Route : 
P -Asserted- Identity: 
Privacy : 

P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Required: 
Supported: 
Contact : 
Content-Type : 
Content-Length : 
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10. 100 Trying (S-CSCF to I-CSCF) - see example in table 17.3.3.1-10 

S-CSCF#2 responds to the INVITE request with a 100 Trying provisional response. 

Table 17.3.3.1-10: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/2. 0/UDP 
[5555 : : aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

11. Evaluation of initial filter criteria 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias.t 

12. INVITE (S-S#lc to MT) - see example in table 17.3.3.1-12 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 

Table 17.3.3.1-12: INVITE (S-S#1c to MT) 

INVITE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Route: sip:pcscf 2 .home2 . net; Ir 

Record-Route : sip:scscf2. home 2 .net;lr, sip: icscf l_s . homel .net;lr, sip:Token(sip:scscfl. homel .net; Ir, 
sip:pcscfl . homel .net; Ir ) (? homel .net; tokenized-by=homel .net 
P-Asserted- Identity : 
Privacy : 

P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 
Call-ID: 
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Cseq: 

Required: 

Supported: 

Contact : 

P-Called-Party-ID : <sip:user2_publicl@home2 . net> 

Content-Type : 

Content-Length: (...) 



v=0 
o= 



2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 



c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=qos : mandatory sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 



13. 100 Trying (MT to S-S#lc) - see example in table 17.3.3.1-13 

S-CSCF#2 receives a 100 Trying provisional response to the INVITE request, as specified by the termination 
procedures. 



Table 17.3.3.1-13: 100 Trying (MT to S-S#1c) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 
pcscf 1 . homel .net; branch=z9hG4bK431h23 . 1 ) (3 homel .net; tokenized-by=homel . 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



net;branch=z9hG4bK312a32. 1, 
net, SIP/2. 0/UDP 



14. 183 Session Progress (MT to S-S#lc) - see example in table 17.3.3.1-14 (related to 17.3.3.1-12) 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response to the INVITE request, as per the termination procedure. 



Table 17.3.3.1-14: 183 Session Progress (MT to S-S#1c) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s. homel. net ;branch=z9hG4bK871y 12. 1, SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK3 12a3 2 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf l_s .homel . net; Ir, 
sip: Token (sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir ) (? homel .net; tokenized-by=homel .net 
P-Asserted-Identity : "John Smith" <sip:user2_publicl(3homel . net> 
Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 

To: sip : user2_publicl@home2 . net ; tag=314159 
Call-ID: 
CSeq: 

Require: lOOrel 
Contact: sip: [5555: 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 



:eee:fff:aaa: bbb] 



v=0 

o=- 2987933615 2987933615 



IN IP6 5555: :aaa:bbb:ccc:ddd 
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c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 3 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=qos : mandatory sendrecv confirm 

m=audio RTP/AVP 97 96 15 



15. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 17,3.3.1-15 

S-CSCF#2 forwards the 183 Session Progress provisional response to I-CSCF#2. 

Table 17.3.3.1-15: 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip:user2_publicl@homel . net> 
Privacy: none 

P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 
Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 
ecf=[5555::lff:2ee:3dd:4cc]; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



P-Charging- Vector: The S-CSCF adds the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 

16. 183 Session Progress (I-CSCF to I-CSCF) - see example in table 17.3.3.1-16 

I-CSCF#2 forwards the 183 Session Progress provisional response to I-CSCF#1. 

Table 17.3.3.1-16: 183 Session Progress (I-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf l_s .homel . net;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, SIP/ 2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1) (Shomel . net; tokenized- 
by=homel . net, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 
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Record-Route : 

P-Asserted- Identity : 

Privacy ; 

P -Asserted- Identity : 

Privacy ; 

P-Charging-Vector ; 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



17. 183 Session Progress (I-CSCF to S-CSCF) - see example in table 17.3.3.1-17 

I-CSCF#1 forwards the 183 Session Progress provisional response to S-CSCF#1. 

Table 17.3.3.1-17: 183 Session Progress (I-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscfl_s .homel . net; Ir, 

sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir 

P-Asserted- Identity : 

Privacy : 

P-Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 
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Record-Route: I-CSCF#1 determines the entry to the right of its own entry. 

Via: determined by I-CSCF#1 . 

18. 183 Session Progress (S-S#lc to MO) - see example in table 17.3.3.1-18 

S-CSCF#1 forwards the 183 Session Progress to the originator, as per the originating procedure. 

Table 17.3.3.1-18: 183 Session Progress (S-S#1c to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity: 
Privacy : 

P -Asserted- Identity; 
Privacy : 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 : ; f 5f ; e4e : d3d: c2c] 
From; 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 

c = 

t = 



19. PRACK (MO to S-S#lc) - see example in table 17.3.3.1-19 

The originator decides the final set of media streams, and includes this information in the PRACK request 
sent to S-CSCF#1 by the origination procedures. 

Table 17.3.3.1-19: PRACK (MO to S-S#1c) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscfl_s .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, 
sip:pcscf2 . home 2 .net; Ir 

From: sip : userl_publicl@homel . net ; tag=171828 
To : sip : user2_publicl@home2 .net;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Require: precondition 
Cseq: 128 PRACK 
Rack: 9021 127 INVITE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 
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m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



20. PRACK (S-CSCF to I-CSCF) - see example in table 17.3.3.1-20 

S-CSCF#1 forwards the PRACK request to I-CSCF#1. 

Table 17.3.3.1-20: PRACK (S-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: icscfl_s .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



21. PRACK (I-CSCF to S-CSCF) - see example in table 17.3.3.1-21 

I-CSCF#1 forwards the PRACK request to S-CSCF#2. 

Table 17.3.3.1-21 : PRACK (I-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscfl_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1) @homel . net; tokenized- 
by=homel . net, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route: sip: scscf2 .home2 . net; Ir, sip:pcscf2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 
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22. PRACK (S-S#lc to MT) - see example in table 17.3.3.1-22 

S-CSCF#2 forwards the PRACK request to the terminating endpoint, as per the termination procedure. 

Table 17.3.3.1-22: PRACK (S-S#1c to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



23. 200 OK (MT to S-S#lc) - see example in table 17.3.3.1-23 

The terminating endpoint responds to the PRACK request with a 200 OK response. 

Table 17.3.3.1-23: 200 OK (MT to S-S#1c) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 
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24. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.3.1-24 

S-CSCF#2 forwards the 200 OK response to I-CSCF#1. 

Table 17.3.3.1-24: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, SIP/ 2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1) @homel . net ; tokenized- 
by=homel . net , SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



25. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.3.1-25 

I-CSCF#1 forwards the 200 OK response to S-CSCF#1. 

Table 17.3.3.1-25: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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Via: Determined by I-CSCF#1 . 

26. 200 OK (S-S#lc to MO) - see example in table 17.3.3.1-26 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 17.3.3.1-26: 200 OK (S-S#1c to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



27. UPDATE (MO to S-S#lc) - see example in table 17.3.3.1-27 

When the originating endpoint has completed the resource reservation procedures, it sends the UPDATE 
request to S-CSCF#1 by the origination procedures. 

Table 17.3.3.1-27: UPDATE (MO to S-S#1c) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscfl_s .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, 
sip:pcscf2 . home 2 .net; Ir 

From: sip : userl_publicl@homel . net ; tag=171828 
To : sip : user2_publicl@home2 .net;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 129 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 
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28. UPDATE (S-CSCF to I-CSCF) - see example in table 17.3.3.1-28 

S-CSCF#1 forwards the UPDATE request to I-CSCF#1. 

Table 17.3.3.1-28: UPDATE (S-CSCF to I-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: icscfl_s .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



29. UPDATE (I-CSCF to S-CSCF) - see example in table 17.3.3.1-29 

I-CSCF#1 forwards the UPDATE request to S-CSCF#2. 

Table 17.3.3.1-29: UPDATE (I-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscfl_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, SIP/ 2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK4 31h23 . 1) ghomel . net; tokenized- 
by=homel . net, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



30. UPDATE (S-S#lc to MT) - see example in table 17.3.3.1-30 

S-CSCF#2 forwards the UPDATE request to the terminating endpoint, as per the termination procedure. 
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Table 17.3.3.1-30: UPDATE (S-S#1c to MT) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/ 2 .0/UDP pcscf 1 .homel . net ;branch=z9hG4bK4 31h23 . 1) ghomel . net; tokenized-by=homel . net, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



31. 200 OK (MT to S-S#lc) - see example in table 17.3.3.1-31 

The terminating endpoint responds to the UPDATE request with a 200 OK response. 

Table 17.3.3.1-31 : 200 OK (MT to S-S#1c) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscfl_s. homel. net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 



32. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.3.1-32 

S-CSCF#2 forwards the 200 OK response to I-CSCF#1. 

Table 17.3.3.1-32: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, SIP/ 2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1) ghomel . net ; tokenized- 
by=homel . net , SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
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To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



33. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.3.1-33 

I-CSCF#1 forwards the 200 OK response to S-CSCF#1. 

Table 17.3.3.1-33: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



Via: Determined by I-CSCF#1 . 

34. 200 OK (S-S#lc to MO) - see example in table 17.3.3.1-34 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 17.3.3.1-34: 200 OK (S-S#1c to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



583 



ETSI TS 124 228 V5.3.0 (2002-12) 



35. 180 Ringing (MT to S-S#lc) - see example in table 17.3.3.1-35 (related to table 17.3.3.1-12) 

The terminating endpoint may optionally send a 180 Ringing provisional response indicating alerting is in 
progress. This response is sent by the termination procedure to S-CSCF#2. 



Table 17.3.3.1-35: 180 Ringing (MT to S-S#1c) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 ; : aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip;pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf l_s .homel . net; Ir, 
sip: Token (sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir ) (? homel .net; tokenized-by=homel .net 
From: 
To: 

Call-ID: 
CSeq: 
Require 
Contact 
RSeq: 9022 
Content -Length 



lOOrel 
sip: [5555 : 



: eee : f f f : aaa: bbb] 



36. 180 Ringing (S-CSCF to I-CSCF) - see example in table 17.3.3.1-36 

S-CSCF#2 forwards the 180 Ringing response to I-CSCF#2. 

Table 17.3.3.1-36: 180 Ringing (S-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

icscfl_s. homel. net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/ 2 .0/UDP pcscfl .homel . net ;branch=z9hG4bK4 31h23 . 1) ghomel . net; tokenized-by=homel . net, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

37. 180 Ringing (I-CSCF to I-CSCF) - see example in table 17.3.3.1-37 

I-CSCF#2 forwards the 180 Ringing response to I-CSCF#1. 

Table 17.3.3.1-37: 180 Ringing (I-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, SIP/ 2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1) ghomel . net ; tokenized- 
by=homel . net , SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
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RSeq: 

Content-Length : 



38. 180 Ringing (I-CSCF to S-CSCF) - see example in table 17.3.3.1-38 

I-CSCF#1 forwards the 180 Ringing response to S-CSCF#1. 

Table 17.3.3.1-38: 180 Ringing (I-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscfl_s .homel . net; Ir, 

sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

Record-Route: Formed by I-CSCF#1 determining the entry to the right of its own entry. 

Via: Determined by I-CSCF#1 . 

39. 180 Ringing (S-S#lc to MO) - see example in table 17.3.3.1-39 

S-CSCF#1 forwards the 180 Ringing response to the originator, per the origination procedure. 

Table 17.3.3.1-39: 180 Ringing (S-S#1c to MO) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

40. PRACK (MO to S-S#lc) - see example in table 17.3.3.1-40 

The originator acknowledges the 180 Ringing provisional response (39) with a PRACK request. 

Table 17.3.3.1-40: PRACK (MO to S-S#1c) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscf 1 .homel . net; Ir, sip: icscfl_s .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, 
sip:pcscf2 . home 2 .net; Ir 

From: sip : userl_publicl@homel . net ; tag=171828 
To : sip: user 2_publicl@home2 . net; tag=314159 
Call- ID: cb03a0s0 9a2sdf gilt j 4 90333 
Cseq: 130 PRACK 
Raclt: 9022 127 INVITE 
Content-Length: 



41. PRACK (S-CSCF to I-CSCF) - see example in table 17.3.3.1-41 

S-CSCF#1 forwards the PRACK request to I-CSCF#1. 
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Table 17.3.3.1-41 : PRACK (S-CSCF to l-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: icscfl„s .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

42. PRACK (I-CSCF to I-CSCF) - see example in table 17.3.3.1-42 

I-CSCF#1 forwards the PRACK request to S-CSCF#2. 

Table 17.3.3.1-42: PRACK (I-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscfl_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscfl.homel.net, SIP/ 2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1) @homel . net ; tokenized- 
by=homel . net , SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 67 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 
Content-Length : 

43. PRACK (S-S#lc to MX) - see example in table 17.3.3.1-43 

S-CSCF#2 forwards the PRACK request to the terminating endpoint. 

Table 17.3.3.1-43: PRACK (S-S#1c to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscfl_s. homel. net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: sip:pcscf2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

44. 200 OK (MT to S-S#lc) - see example in table 17.3.3.1-44 

The terminating endpoint responds to the PRACK request (43) with a 200 OK response. 

Table 17.3.3.1-44: 200 OK (MT to S-S#1c) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscfl_s. homel. net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl.homel.net, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 
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45. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.3.1-45 

S-CSCF#2 forwards the 200 OK response to I-CSCF#1. 

Table 17.3.3.1-45: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 1 .homel . net, SIP/ 2 .0/UDP pcscfl .homel . net ;branch=z9hG4bK431h23 . 1) ghomel . net; tokenized- 
by=homel . net, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

46. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.3.1-46 

I-CSCF#1 forwards the 200 OK response to S-CSCF#1. 

Table 17.3.3.1-46: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

Via: Determined by I-CSCF#1 . 

47. 200 OK (S-S#lc to MO) - see example in table 17.3.3.1-47 

S-CSCF#1 forwards the 200 OK response to the originating endpoint. 

Table 17.3.3.1-47: 200 OK (S-S#1c to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

48. 200 OK (MX to S-S#lc) - see example in table 17.3.3.1-48 (related to 17.3.3.1-13) 

The final response to the INVITE (13), 200 OK, is sent by the terminating endpoint over the signalling path. 
This is typically generated when the subscriber has accepted the incoming session attempt. The response is 
sent to S-CSCF#2 per the termination procedure. 

Table 17.3.3.1-48: 200 OK (MT to S-S#1c) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf l_s .homel . net; Ir, 
sip: Token (sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir ) (? homel .net; tokenized-by=homel .net 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 
Contact: sip: [5555: : eee : f f f : aaa:bbb] 
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Content-Length: (...) 

49. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.3.1-49 

The 200 OK response is forwarded to the I-CSCF#2. 

Table 17.3.3.1-49: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) (3homel . net; token! zed-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Type : 
Content-Length : 

50. 200 OK (I-CSCF to I-CSCF) - see example in table 17.3.3.1-50 

The 200 OK response is forwarded to I-CSCF#1. 

Table 17.3.3.1-50: 200 OK (I-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP 
Token (sip:scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

51. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.3.1-51 

The 200 OK response is forwarded to S-CSCF#1. 

Table 17.3.3.1-51 : 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf l_s .homel . net; Ir, 

sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

Record-Route: Formed by I-CSCF#1 determining the entry to the right of its own entry. 

Via: Determined by I-CSCF#1 . 

52. 200 OK (S-S#lc to MO) - see example in table 17.3.3.1-52 

The 200 OK response is returned to the originating endpoint, by the origination procedure. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 588 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Table 17.3.3.1-52: 200 OK (S-S#1c to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

53. ACK (MO to S-S#lc) - see example in table 17.3.3.1-53 

The originating endpoint sends the final acknowledgement to S-CSCF#1 by the origination procedures. 

Table 17.3.3.1-53: ACK (MO to S-S#1c) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscfl_s .homel . net ; Ir, sip: scscf 2 .home2 . net; Ir, 
sip:pcscf2 . home 2 .net; Ir 

From: sip : userl_publicl@homel . net ; tag=171828 
To : sip: user 2_publicl@home2 . net; tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 ACK 
Content-Length: 

54. ACK (S-CSCF to I-CSCF) - see example in table 17.3.3.1-54 

S-CSCF#1 forwards the ACK request to I-CSCF#1. 

Table 17.3.3.1-54: ACK (S-CSCF to I-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: icscfl_s .homel . net; Ir, sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

55. ACK (I-CSCF to S-CSCF) - see example in table 17.3.3.1-55 

I-CSCF#1 forwards the ACK request to S-CSCF#2. 

Table 17.3.3.1-55: ACK (I-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscfl_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Tolien (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; to]tenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

56. ACK (S-S#lc to MX) - see example in table 17.3.3.1-56 
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S-CSCF#2 forwards the ACK request to the terminating endpoint, as per the termination procedure. 

Table 17.3.3.1-56: ACK (S-S#1c to MT) 

ACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Route: sip:pcscf2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



17.3.3.2 Termination failure (not provided) 

An example of this flow is not shown in the present document. 

17.3.3.3 Origination failure (not provided) 

An example of this flow is not shown in the present document. 

17.3.4 S-S#1d 

17.3.4.1 (S-S#1d) Different network operators performing origination and termination, 

with configuration hiding by terminating network operator (M0#2, MT#2 
assumed) 

Figure 17.3.4.1-1 shows a S-CSCF handling session origination (S-CSCF#1) which performs an analysis of the 
destination address, and determines that it belongs to a subscriber of a different operator. S-CSCF#1 forwards the 
request to a well-known entry point in the destination operator's network, I-CSCF#2. 1-CSCF#2 queries the HSS for 
current location information, and finds the S-CSCF assigned to the subscriber (S-CSCF#2), and forwards the request to 
S-CSCF#2. The terminating network operator desires to keep their configuration hidden, so I-CSCF#2 inserts itself into 
the signalling path for future exchanges. 

Origination sequences that share this common S-CSCF to S-CSCF procedure are: 

MO#la Mobile origination, roaming, without a THIG. The "Originating Network" of S-S#ld is therefore a 

visited network. 

MO#lb Mobile origination, roaming, with a THIG in home network. The "Originating Network" of S- 

S#ld is therefore a visited network. 

MO#2 Mobile origination, located in home service area. The "Originating Network" of S-S#ld is 

therefore the home network. 

CS-O CS Networks origination. The "Originating Network" of S-S#ld is the home network. The element 

labeled S-CSCF#1 is the MGCF of the CS-O procedure. 

Termination sequences that share this common S-CSCF to S-CSCF procedure are: 

MT#la Mobile termination, roaming, without a THIG. The "Terminating Network" of S-S#ld is a visited 

network. 

MT#lb Mobile termination, roaming, with a THIG in home network. The "Terminating Network" of S- 

S#ld is a visited network. 

MT#2 Mobile termination, located in home service area. The "Terminating Network" of S-S#ld is the 

home network. 
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Figure 17.3.4.1-1: S-S#1d 

Procedure S-S#ld is as follows: 

1 . INVITE (MO to S-S#ld) - see example in table 17.3.4,1-1 

The INVITE request is sent from the UE to S-CSCF#1 by the procedures of the originating signalling flow. 
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Table 17.3.4.1-1 : INVITE (MO to S-S#1d) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 69 
Route; sip; scscfl .homel . net; Ir 
Record-Route ; sip;pcscfl. homel .net; Ir 

P-Asserted-Identity; "John Doe" <tel ; +l-212-555-llll> 
Privacy; none 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; dSd; c2c] 
From; sip ; userl_publicl@homel . net ; tag=171828 
To; sip ; user2_publicl@home2 . net 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 127 INVITE 
Require; precondition 
Supported; lOOrel 

Contact; sip; [5555; ; aaa; bbb; ccc ; ddd] 
Content-Type; application/sdp 
Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ;; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555 ; ;aaa;bbb; ccc;ddd 

t=907165275 

m=video 34 00 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap: 99;MPV 

m=video 3402 RTP/AVP 99 

b=AS;54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap; 99;MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS;25.4 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

m=audio 3458 RTP/AVP 97 96 15 

b=AS;25.4 

a=rtpmap;97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

2. 100 Trying (S-S#ld to MO) - see example in table 17.3.4.1-2 

S-CSCF#1 responds to the INVITE request (1) with a 100 (Trying) provisional response. 

Table 17.3.4.1-2: 100 Trying (S-S#1d to MO) 

SIP/2.0 100 Trying 

Via; SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To; 

Call-ID; 
CSeq; 
Content-Length; 
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3. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For this 
example, assume no Application Server involvement. 

S-CSCF#1 examines the media parameters, and removes any choices that the subscriber does not have 
authority to request. 

For this example, assume the subscriber is not allowed video. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 17.3.4.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. S-CSCF#1 forwards the INVITE request to I-CSCF#2, the well-known entry 
point of the destination network. 

Table 17.3.4.1-4: INVITE (S-CSCF to I-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Record-Route: sip : scscf 1 . homel . net ; Ir, sip:pcscfl .homel . net ; Ir 

Route: sip: icscf 2_s .home2 . net; Ir 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 

Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 
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P-Asserted-Identity: The S-CSCF adds the corresponding TEL URL to the P-Asserted-Identity header in order that 
the TEL URL is known to the destination network in case the INVITE is forwarded to a MGCF. 

P-Charging- Vector: The S-CSCF adds the identifier of its own network to the originating Inter Operator Identifier 
(lOI) parameter of this header. 

5. 100 Trying (I-CSCF to I-CSCF) - see example in table 17.3.4.1-5 

I-CSCF#2 respond to the INVITE request (4) with a 100 (Trying) provisional response. 

Table 17.3.4.1-5: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

6. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228. 

Table 7.3.2.1-6a provides the parameters in the SIP INVITE message (flow 4) which need to be sent to HSS. 

Table 7.3.2. l-6b provides the parameters sent from the HSS that need to be mapped to SIP INVITE (flow 7) 
and sent to S-CSCF. 

7. INVITE (I-CSCF to S-CSCF) - see example in table 17.3.4.1-7 

I-CSCF#2 forwards the INVITE request to the S-CSCF (S-CSCF#2) that will handle the session termination. 

Table 17.3.4.1-7: INVITE (I-CSCF to S-CSCF) 

INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 1 .home2 . net; Ir 

Record-Route: sip : icscf 2_s . home2 . net ; Ir, sip : scscf 1 . homel . net ; Ir, sip:pcscfl .homel . net ; Ir 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 
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8. 100 Trying (S-CSCF to I-CSCF) - see example in table 17.3.4.1-8 

S-CSCF#2 responds to the INVITE request (7) with a 100 (Trying) provisional response. 

Table 17.3.4.1-8: 100 Trying (S-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pes cf 1 . home 1 . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

9. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. For this 
example, assume no Application Server involvement 

S-CSCF#2 performs whatever service control logic is appropriate for this session attempt. 

S-CSCF#2 examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. 

For this example, assume the destination subscriber is not allowed stereo, so only a single audio stream is 
permitted. 

10. INVITE (S-S#ld to MT) - see example in table 17.3.4.1-10 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. 

Table 17.3.4.1-10: INVITE (S-S#1d to MT) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1, SIP/ 2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b2 3 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: sip:pcscf 2 .home2 . net; Ir 

Record-Route: sip: scscf 2 .home2 . net; Ir, sip: icscf 2_s .home2 . net; Ir, sip: scscf 1 .homel . net ; Ir, 
sip:pcscfl . homel .net; Ir 
P-Asserted- Identity : 
Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
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To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

P-Called-Party-ID : sip:user2_publicl@home2 . net 

Content-Type : 

Content-Length: (...) 



v=0 



o= 



2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
aaa : bbb : ccc : ddd 



c=IN IP6 5555 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



1 1. 100 Trying (MT to S-S#ld) - see example in table 17.3.4.1-11 

S-CSCF#2 receives a 100 (Trying) provisional response to the INVITE request (10), as specified by the 
termination procedures. 

Table 17.3.4.1-11: 100 Trying (MT to S-S#1d) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

12. 183 Session Progress (MT to S-S#ld) - see example in table 17.3.4.1-12 

The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session 
Progress) provisional response to the INVITE request (10), as per the termination procedure. 
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Table 17.3.4.1-12: 183 Session Progress (MT to S-S#1d) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 . home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf2_s .home2 . net; Ir, 
sip: scscfl . homel .net;lr, sip:pcscfl.visitedl.net;lr 
P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net> 
Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 

To : sip:user2_publicl@home2 . net; tag=314159 
Call-ID: 
CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: eee : fff : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 3 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

13. 183 Session Progress (S-CSCF to I-CSCF) - see example in table 17.3.4.1-13 

S-CSCF#2 forwards the 183 (Session Progress) provisional response to I-CSCF#2. 

Table 17.3.4.1-13: 183 Session Progress (S-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e661; ccf=[5555: :a55:b44:c33:d221; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc: 9ddl 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 
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P-Charging- Vector: The S-CSCF adds the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 

14. 183 Session Progress (I-CSCF to S-CSCF) - see example in table 17.3.4.1-14 

I-CSCF#2 forwards the 183 (Session Progress) provisional response to S-CSCF#1. 

Table 17.3.4.1-14: 183 Session Progress (I-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : sip:token(sip:pcscf2. home 2 .net;lr, sip:scscf2. home 2 .net; Ir ) @ home 2 .net;tokenized- 

by=home2 . net, sip: icscf 2_s .home2 . net; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscf 1 . visitedl . net; Ir 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



Record-Route: The I-CSCF#2 tokenizes the entries of its own network 

15. 183 Session Progress (S-S#ld to MO) - see example in table 17.3.4.1-15 

S-CSCF#1 forwards the 183 Session Progress to the originator, as per the originating procedure. 

Table 17.3.4.1-15: 183 Session Progress (S-S#1d to MO) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 
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Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length ; 



16. PRACK (MO to S-S#ld) - see example in table 17.3.4.1-16 

The originator decides the final set of media streams, and includes this information in the PRACK request 
sent to S-CSCF#1 by the origination procedures. 

Table 17.3.4.1-16: PRACK (MO to S-S#1d) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir^ sip: token (sip:pcscf 2 .home2 . net; Ir^ 
sip: scscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: sip : userl_publicl@homel .net;tag=171828 
To : sip : user2__publicl@home2 .net;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 128 PRACK 
Require: precondition 
Rack: 9021 127 INVITE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 



17. PRACK (S-CSCF to I-CSCF) - see example in table 17.3.4.1-17 

S-CSCF#1 forwards the PRACK request to 1-CSCF#2. 

Table 17.3.4.1-17: PRACK (S-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:pcscf2. home 2 .net; Ir, 

sip: scscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 



18. PRACK (I-CSCF to S-CSCF) - see example in table 17.3.4.1-18 

I-CSCF#2 determines the routing information, and forwards the PRACK request to S-CSCF#2. 

Table 17.3.4.1-18: PRACK (I-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



19. PRACK (S-S#ld to MT) - see example in table 17.3.4.1-19 

S-CSCF#2 forwards the PRACK request to the terminating endpoint, as per the termination procedure. 

Table 17.3.4.1-19: PRACK (S-S#1d to MT) 
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PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



20. 200 OK (MT to S-S#ld) - see example in table 17.3.4.1-20 

The terminating endpoint responds to the PRACK request (19) with a 200 (OK) response. 

Table 17.3.4.1-20: 200 OK (MT to S-S#1d) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1, SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: eee : fff : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

21. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.4.1-21 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 

Table 17.3.4.1-21 : 200 OK (S-CSCF to I-CSCF) 
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SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



22. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.4.1-22 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table 17.3.4.1-22: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o= 
s = 
c= 

t = 



23. 200 OK (S-S#ld to MO) - see example in table 17.3.4.1-23 

S-CSCF#1 forwards the 200 (OK) response to the originating endpoint. 

Table 17.3.4.1-23: 200 OK (S-S#1d to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
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Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



24. UPDATE (MO to S-S#ld) - see example in table 17.3.4.1-24 

When the originating endpoint has completed the resource reservation procedures, it sends the UPDATE 
request to S-CSCF#1 by the origination procedures. 

Table 17.3.4.1-24: UPDATE (MO to S-S#1d) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscfl .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, sip: token (sip:pcscf 2 .home2 . net; Ir, 
sip: scscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: sip : userl_publicl@homel .net;tag=171828 
To : sip : user2_publicl@home2 .net;tag=314159 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 12 9 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

m=audio RTP/AVP 97 96 15 

25. UPDATE (S-CSCF to I-CSCF) - see example in table 17.3.4.1-25 

S-CSCF#1 forwards the UPDATE request to I-CSCF#2. 

Table 17.3.4.1-25: UPDATE (S-CSCF to I-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:pcscf2. home 2 .net; Ir, 

sip: scscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 

From: 
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To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



26. UPDATE (I-CSCF to S-CSCF) - see example in table 17.3.4.1-26 

I-CSCF#2 forwards the UPDATE request to S-CSCF#2. 

Table 17.3.4.1-26: UPDATE (I-CSCF to S-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pes cf 1 . home 1 . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



27. UPDATE (S-S#ld to MT) - see example in table 17.3.4.1-27 

S-CSCF#2 forwards the UPDATE request to the terminating endpoint, as per the termination procedure. 

Table 17.3.4.1-27: UPDATE (S-S#1d to MT) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2„s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 
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Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



28. 200 OK (MT to S-S#ld) - see example in table 17.3.4.1-28 

The terminating endpoint responds to the UPDATE request (27) with a 200 (OK) response. 

Table 17.3.4.1-28: 200 OK (MT to S-S#1d) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: eee : fff : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

29. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.4.1-29 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 

Table 17.3.4.1-29: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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30. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.4.1-30 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table 17.3.4.1-30: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



31. 200 OK (S-S#ld to MO) - see example in table 17.3.4.1-31 

S-CSCF#1 forwards the 200 (OK) response to the originating endpoint. 

Table 17.3.4.1-31 : 200 OK (S-S#1d to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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32. 180 Ringing (MT to S-S#ld) - see example in table 17.3.4.1-32 

The terminating endpoint may optionally send a 180 (Ringing) provisional response indicating alerting is in 
progress. This response is sent by the termination procedure to S-CSCF#2. 



Table 17.3.4.1-32: 180 Ringing (MT to S-S#1d) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route; sip;pcscf2 .home2 . net; Ir, sip; scscf 2 .home2 . net; Ir, sip; icscf 2_s .home2 . net; Ir, 
sip; scscfl . homel .net;lr, sip;pcscfl.visitedl.net;lr 
From; 
To; 

Call-ID; 
CSeq; 
Require 
Contact 
RSeq; 9022 
Content-Length ; 



lOOrel 
sip; [5555 ; 



; eee ; f f f ; aaa;bbb] 



33. 180 Ringing (S-CSCF to I-CSCF) - see example in table 17.3.4.1-33 

S-CSCF#2 forwards the 180 (Ringing) response to I-CSCF#2. 

Table 17.3.4.1-33: 180 Ringing (S-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via; SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555; ; aaa :bbb : ccc ; ddd] ;branch=z9hG4bKnashds7 

Record-Route ; 

From; 

To; 

Call-ID; 

CSeq; 

Require ; 

Contact ; 

RSeq; 

Content-Length ; 

34. 180 Ringing (I-CSCF to S-CSCF) - see example in table 17.3.4.1-34 

I-CSCF#2 forwards the 180 (Ringing) response to S-CSCF#1. 



Table 17.3.4.1-34: 180 Ringing (I-CSCF to S-CSCF) 



SIP/2.0 180 Ringing 

Via; SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 



pcscf 1 . homel 

Record-Route 

by=home2 . net 

From; 

To; 

Call-ID; 

CSeq; 

Require ; 

Contact ; 

RSeq; 

Content -Length 



net;branch=z9hG4bK431h23. 1, 
sip;token (sip;pcscf2 . home 2 . 
sip ; icscf 2_s . home 2 .net; Ir, 



SIP/ 2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 



net;lr, sip; scscf 2 .home2 . 
sip; scscfl . homel .net; Ir, 



net; Ir ) @ home 2 .net;tokenized- 
sip;pcscfl .visitedl . net; Ir 
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35. 180 Ringing (S-S#ld to MO) - see example in table 17.3.4.1-35 

S-CSCF#1 forwards the 180 (Ringing) response to the originator, per the origination procedure. 

Table 17.3.4.1-35: 180 Ringing (S-S#1d to MO) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc: ddd] ;branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 

36. PRACK (MO to S-S#ld) - see example in table 17.3.4.1-36 

The originator acknowledges the 180 (Ringing) provisional response (35) with a PRACK request. 

Table 17.3.4.1-36: PRACK (MO to S-S#1d) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip : scscfl . homel . net ; Ir, sip: icscf 2_s .home2 . net; Ir, sip: token (sip:pcscf 2 .home2 . net; Ir, 
sip: scscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: sip : userl_publicl@homel .net;tag=171828 
To : sip : user2_publicl@home2 .net;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 130 PRACK 
Rack: 9022 127 INVITE 
Content-Length: 

37. PRACK (S-CSCF to I-CSCF) - see example in table 17.3.4.1-37 

S-CSCF#1 forwards the PRACK request to 1-CSCF#2. 

Table 17.3.4.1-37: PRACK (S-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:pcscf2. home 2 .net; Ir^ 

sip: scscf2 . home 2 . net ; Ir ) @ home 2 .net; tokenized-by=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

38. PRACK (I-CSCF to S-CSCF) - see example in table 17.3.4.1-38 

I-CSCF#2 determines the routing information, and forwards the PRACK request to S-CSCF#2. 

Table 17.3.4.1-38: PRACK (I-CSCF to S-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 
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To: 

Call-ID: 
Cseq: 
Rack: 

Content-Length : 



39. PRACK (S-S#ld to MT) - see example in table 17.3.4.1-39 

S-CSCF#2 forwards the PRACK request to the terminating endpoint. 

Table 17.3.4.1-39: PRACK (S-S#1d to MT) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/2. 0/UDP scscf.homel.net, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: && 

Route: sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

40. 200 OK (MT to S-S#ld) - see example in table 17.3.4.1-40 

The terminating endpoint responds to the PRACK request (39) with a 200 (OK) response. 

Table 17.3.4.1-40: 200 OK (MT to S-S#1d) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

41. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.4.1-41 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 

Table 17.3.4.1-41 : 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscf 1 .homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

42. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.4.1-42 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table 17.3.4.1-42: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 
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Call-ID: 
CSeq: 
Content-Length : 



43. 200 OK (S-S#ld to MO) - see example in table 17.3.4.1-43 

S-CSCF#1 forwards the 200 (OK) response to the originating endpoint. 

Table 17.3.4.1-43: 200 OK (S-S#1d to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

44. 200 OK (MT to S-S#ld) - see example in table 17.3.4.1-44 

The final response to the INVITE (10), 200 (OK) response, is sent by the terminating endpoint over the 
signalling path. This is typically generated when the subscriber has accepted the incoming session attempt. 
The response is sent to S-CSCF#2 per the termination procedure. 

Table 17.3.4.1-44: 200 OK (MT to S-S#1d) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2„s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .home2 . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 .home2 . net; Ir, sip: scscf 2 .home2 . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip: scscfl . homel .net;lr, sip:pcscfl.visitedl.net;lr 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 
Content-Length: 

45. 200 OK (S-CSCF to I-CSCF) - see example in table 17.3.4.1-45 

The 200 (OK) response is forwarded to the I-CSCF#2. 

Table 17.3.4.1-45: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

46. 200 OK (I-CSCF to S-CSCF) - see example in table 17.3.4.1-46 

The 200 (OK) response is forwarded to S-CSCF#1. 

Table 17.3.4.1-46: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Record-Route : sip: token (sip:pcscf 2 .home 2 . net; Ir, sip:scscf2 .home 2 . net; Ir) @home2 . net; tokenized- 
by=home2 . net, sip : icscf 2_s . home2 . net ; Ir, sip: scscf 1 .homel . net; Ir, sip:pcscf 1 . visitedl . net; Ir 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

47. 200 OK (S-S#ld to MO) - see example in table 17.3.4.1-47 

The 200 (OK) response is returned to the originating endpoint, by the origination procedure. 

Table 17.3.4.1-47: 200 OK (S-S#1d to MO) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ; branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 

48. ACK (MO to S-S#ld) - see example in table 17.3.4.1-48 

The originating endpoint sends the final acknowledgement to S-CSCF#1 by the origination procedures. 

Table 17.3.4.1-48: ACK (MO to S-S#1d) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscfl . homel . net ;branch=z9hG4bK431h23 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: sip: scscf 1 .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, sip: token (sip:pcscf2 .home2 . net; Ir, 
sip: scscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 
From: sip : userl_publicl@homel .net;tag=171828 
To : sip : user2_publicl@home2 .net;tag=314159 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 ACK 
Content-Length: 

49. ACK (S-CSCF to I-CSCF) - see example in table 17.3.4.1-49 

S-CSCF#1 forwards the ACK request to I-CSCF#2. 

Table 17.3.4.1-49: ACK (S-CSCF to I-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:pcscf2. home 2 .net; Ir, 

sip: scscf2 . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

50. ACK (I-CSCF to S-CSCF) - see example in table 17.3.4.1-50 

I-CSCF#2 forwards the ACK request to S-CSCF#2. 

Table 17.3.4.1-50: ACK (I-CSCF to S-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 
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Via: SIP/2. 0/UDP icscf 2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 2 .home2 . net; Ir, sip:pcscf 2 .home2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

51. ACK (S-S#ld to MT) - see example in table 17.3.4.1-51 

S-CSCF#2 forwards the ACK request to the terminating endpoint, as per the termination procedure. 

Table 17.3.4.1-51 : ACK (S-S#1d to MT) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route: sip:pcscf 2 .home2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



17.3.4.2 Termination failure (not provided) 

An example of this flow is not shown in the present document. 

17.3.4.3 Origination failure (not provided) 

An example of this flow is not shown in the present document. 

17.3.5 Not applicable 

Void. 

17.3.6 S-S#3 

17.3.6.1 (S-S#3) PSTN Termination performed by home network of originator (not 

provided) 

An example of this flow is not shown in the present document. 

17.3.7 S-S#4 

17.3.7.1 (S-S#4) PSTN Termination performed by different operator than origination 

(not provided) 

An example of this flow is not shown in the present document. 
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17.4 Termination procedures 

17.4.1 Introduction 

See subclause 7.4.1. 

17.4.2 l\/IT#1b 

1 7.4.2.1 (MT#1 b) Mobile termination, roaming (M0#2, S-S#2 assumed) 

Figure 17.4.2.1-1 shows a termination procedure which applies to roaming subscribers when the home network operator 
desires to keep its internal configuration hidden from the visited network. The UE is located in a visited network, and 
determines the P-CSCF via the P-CSCF discovery procedure. During registration, the home network allocates a S- 
CSCF. The home network advertises an I-CSCF as the entry point from the visited network, who protects the S-CSCF 
identity and forwards requests to the P-CSCF. 

When registration is complete, S-CSCF knows the name/address of its next hop in the signalling path toward the UE, 
the I-CSCF, and the S-CSCF knows the UE Contact address. I-CSCF receives information in the request, which it 
translates and obtains the name/address of P-CSCF, and P-CSCF obtains the name/address of the UE. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



613 



ETSI TS 124 228 V5.3.0 (2002-12) 



Home Network 



Visited Network 



S-CSCF 



■1. INVITE- 
- 2. 100 — 



l-CSCF 
(THIG) 



3. Evaluation of 
initial Filter Criteria 



-14.183 ■ 
15. PRACK 



22. 200 
OK 



-24. UPDAT 



31. 200 
OK 



35. 180 
Ringing 

36. PRACK- 



-43. 200 OK - 

■47. 200 OK — 
— 48. ACK H 



■4. INVITE- 
— 7. 100 — 



13. 183 



H6. PRACK 



21. 200 
OK 



34. 180 _ 
Ringing 



37. PRACI^ 



42. 200 OK- 



46. 200 OK- 



-49. ACK 



-25. UPDATE ► 



30. 200 
OK 



P-CSCF 



5- INVITE_ 
-6. 100 — 



UE#2 



.8. INVITE ^ 

— 9. 100 



10. 183 



11. Authorize QoS 
Resources 



12. 183 



-17. PRACK 



20. 200 
OK 



■ 26. UPDATE- 



29. 200 
OK 



_33. 180 _ 
Ringing 



38. PRACK 



41. 200OK- 
45. 200 OK- 



■50. ACK ■ 



Figure 17.4.2.1-1: MT#1b 



18. PRACK ^ 



19. 200 
OK 



23. Resource 
Reservation 



■27. UPDATE ► 

28. 200 

OK 



32. 180 
Ringing 



39. PRACK" 

40. 200 OK- 

44. 200 OK- 



51. ACK 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 61 4 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Procedure MT#lb is as follows: 

1 . INVITE (S-S to MT#lb) - see example in table 17.4.2.1-1 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 

Table 17.4.2.1-1 : INVITE (S-S to MT#1b) 

INVITE sip: user2_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .homel . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: scscf 2 .homel . net; Ir 

Record-Route: sip: scscf 1 .homel . net; Ir, sip:pcscfl .homel . net; Ir 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 

Privacy: none 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip:user2_publicl@home2 . net 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: preconditions 

Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecva=rtpmap: 98 H261 

a=rtpmap : 9 9 : MP V 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecva=rtpmap: 98 H261 

a=rtpmap: 99:MPV 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio 3458 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

SDP The SDP contains the complete set of supported codecs from the session originator, as restricted 

by the originating network operator. The "m=" lines for the video media streams show a port 
number zero, which removes them from the negotiation. 
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Upon receipt of the INVITE, the S-CSCF stores the following information about this session, for use in 
providing enhanced services, charging or in possible error recovery actions - see example in table 17.4.2.1- 
Ib. 

Table 17.4.2. 1-1b: Storage of information at S-CSCF 



Request-URI ; sip; user2_publicl@homel.net 

From: sip : userl_publicl@homel . net ; tag=171828 

To; sip ; user2_publicl@home2 . net 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq(2dest): 127 INVITE 

CSeq(2orig) : none 

Route (2orig) ; sip;scscfl. homel .net;lr, sip;pcscfl. homel .net;lr, sip; [5555; ;aaa; bbb ; ccc ; ddd] 

Route(2dest) ; sip ; icscf2_p . homel . net ; Ir, sip ; pcscf 2 . visited2 . net ; Ir, 

sip; [5555; ; eee ; f f f ; aaa;bbb] 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] ; orig- 

ioi=homel . net 

2. 100 Trying (MT#lb to S-S) - see example in table 17.4.2.1-2 

S-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 17.4.2.1-2: 100 Trying (MT#1b to S-S) 

SIP/2.0 100 Trying 

Via; SIP/2. 0/UDP icscf2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555; ; aaa ; bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From; 

To; 

Call-ID; 

CSeq; 

Content-Length; 

3. Evaluation of initial filter criteria 

S-CSCF validates the service profile of this subscriber, and evaluates the initial filter criteria. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 17.4.2.1-4 

S-CSCF remembers (from the registration procedure) the UE Contact address and the next hop CSCF for this 
UE. It forwards the INVITE to the I-CSCF to perform the THIG functions. 

S-CSCF examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. For this example, assume the destination subscriber is not allowed stereo, so only a 
single audio stream is permitted. 

Table 17.4.2.1-4: INVITE (S-CSCF to I-CSCF) 

INVITE sip; [5555 ;; eee ; fff ; aaa ; bbb] SIP/2.0 

Via; SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.homel.net;branch=z9hG4bK871yl2. 1, S IP /2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 ; ; aaa; bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards; 66 

Route; sip; icscf2_p . homel . net ; Ir, sip ; pcscf 2 . visited2 . net ; Ir 

Record-Route; sip; scscf 2 .homel . net; Ir, sip; scscf 1 .homel . net; Ir, sip;pcscfl .homel . net; Ir 
P -Asserted- Identity ; 
Privacy ; 

P-Asserted-Identity; "John Doe" <tel ; +l-212-555-llll> 
Privacy; none 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
P-Charging-Funct ion-Addresses; ccf=[5555; ;b99;c88;d7 7;e66]; ccf=[5555; ;a55;b44;c33;d22]; 
ecf=[5555; ; If f ; 2ee ; 3dd; 4cc] ; ecf=[5555; ; 6aa ; 7bb ; 8cc ; 9dd] 
From; 
To; 

Call-ID; 
Cseq; 
Require ; 
Supported; 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



616 



ETSI TS 124 228 V5.3.0 (2002-12) 



Contact : 

P-Called-Party-ID; <sip: user2_publicl@home2 . net> 

Content-Type ; 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54.6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos none remote sendrecva=rtpmap: 98 H261 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecva=rtpmap; 98 H261 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Via:/Record-Route: 
SDP 



S-CSCF adds itself in the Record-Route and Via headers. 

The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 
lines for the second audio stream shows a port number zero, which removes it from the 
negotiation. 



Request-URI: Built from the registration information. 

Route: Built from the Contact address stored at registration. 

P-Called-Party-ID: Includes the dialled URL with its parameters. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 
5. INVITE (I-CSCF to P-CSCF) - see example in table 17.4.2.1-5 

I-CSCF translates the Via headers in the request, and forwards the INVITE request to P-CSCF. 

Table 17.4.2.1-5: INVITE (I-CSCF to P-CSCF) 

INVITE sip:pcscf2. visited2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2„p.homel . net; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP icscf 2_s . home 1 . net; branch=z9hG4bK871yl2 . 1, 
SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) (ahomel . net; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 
Max-Forwards ; 65 

Route : sip;pcscf2.visited2.net;lr 

Record-Route : sip: icscf 2_p. homel . net; Ir, sip: Token (sip:scscf2 .homel . net; Ir, sip:scscfl .homel . net; Ir, 
sip:pcscfl . homel .net; Ir ) (§ homel .net; tokenized-by=homel .net 
P -As sorted- Identity : 
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Privacy ; 

P -Asserted- Identity : 

Privacy ; 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

P-Called-Party-ID : 

Content-Type : 

Content-Length : 



Via: Translated to preserve configuration independence of the home network. 

Record-Route: Translated to preserve configuration independence of the home network. 

P CSCF saves information from the received INVITE request. The saved value of the information for this 
session is - see example in table 17.4.2. l-5b: 

Table 17.4.2. 1-5b: Storage of information at P-CSCF 

! Request-URI: sip : [5555 :: eee : fff : aaa : bbb] 
From: sip : userl_publicl@homel . net ; tag=171828 
To: sip:user2__publicl@home2 . net 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
CSeq(2dest): 127 INVITE 
CSeq(2orig) : none 

Route (2dest) : sip: [5555: :eee:fff: aaa: bbb] 

Route(2orig) : sip : icscf 2_p . homel . net ; Ir, sip : Token (sip : scscf 2 . homel . net ; Ir, 
sip: cscfl . homel .net;lr, sip:pcscfl. homel .net; Ir ) @ homel .net; tokenized-by=homel .net 
P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 



6. 100 Trying (P-CSCF to I-CSCF) - see example in table 17.4.2.1-6 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 61 8 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

P-CSCF responds to the INVITE request (5) with a 100 Trying provisional response. 
Table 17.4.2.1-6: 100 Trying (P-CSCF to l-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2„p . homel . net ;branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 

scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, 

SIP/ 2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1) ghomel . net ; tokenized-by=homel . net , S IP /2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

7. 100 Trying (I-CSCF to S-CSCF) - see example in table 17.4.2.1-7 

I-CSCF determines the Via header, and forwards the 100 Trying provisional response to S-CSCF. 

Table 17.4.2.1-7: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

8. INVITE (P-CSCF to UE) - see example in table 17.4.2.1-8 

P-CSCF examines the media parameters, and removes any that the network operator decides, based on local 
policy, not to allow on the network. 

For this example, assume the network operator does not allow 64 kb/s audio, so the PCMU codec is removed. 

P-CSCF removes the Record-Route and Via headers, calculates the proper Route header to add to future 
requests, and saves that information without passing it to UE. 

Table 17.4.2.1-8: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards : 64 

P-Media-Authorization: 0020000100100101706466322e76697369746564322e6e6574000c020133315331343363231 

P -Asserted- Identity: 

Privacy : 

P -As sorted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

P-Called-Party-ID : 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 :: aaa: bbb: ccc: ddd 

t=907165275 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 
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a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecva=rtpmap; 98 H261 

a=rtpmap: 99:MPV 

m=video RTP/AVP 99 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecva=rtpmap; 98 H261 

a=rtpmap : 9 9 : MP V 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 96 15 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

b=AS:25.4 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saves 
values. It inserts this as a branch value on its Via header. 



P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.visited2.net" with credentials "31814621". 



SDP 



The SDP contains the restricted set of codecs allowed by the network operator. The "m=" 
lines for the first audio stream no longer contains codec "0" (PCMU), which removes it 
from the negotiation. 



9. 100 Trying (UE to P-CSCF) - see example in table 17.4.2.1-9 

UE may optionally send a 100 Trying provisional response to P-CSCF. 

Table 17.4.2.1-9: 100 Trying (UE to P-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length: 

10. 183 Session Progress (UE to P-CSCF) - see example in table 17.4.2.1-10 

UE#2 determines the complete set of codecs that it is capable of supporting for this session. It determines the 
intersection with those appearing in the SDP in the INVITE request. For each media flow that is not 
supported, UE#2 inserts a SDP entry for media (m= line) with port=0. For each media flow that is supported, 
UE#2 inserts a SDP entry with an assigned port and with the codecs in common with those in the SDP from 

UE#1. 

For this example, assume UE#2 supports both AMR and G726, but not G728 (code 15). 

UE responds with a 183 Session Progress response containing SDP back to the originator. This SDP may 
represent one or more media for a multimedia session. This response is sent to P-CSCF. 

Table 17.4.2.1-10: 183 Session Progress (UE to P-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK361k21 . 1 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 620 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

P-Asserted-Identity : "John Smith" <sip:user2_publicl@homel . net> 

Privacy; none 

From; 

To; sip ; user2_publicl@home2 . net ; tag=314159 

Call-ID; 

CSeq; 

Require; lOOrel 

Contact; sip; [5555; ; eee ; f f f ; aaa;bbb] 

RSeq; 9021 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ; ; aaa ; bbb ; ccc ; ddd 

s=- 

c=IN IP6 5555; ;eee;fff ;aaa;bbb 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 6544 RTP/AVP 97 96 

b=AS;25.4 

a=curr;qos local none 

a=curr;qos remote none 

a=des;qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=rtpmap;97 AMR 

a=fmtp;97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap;96 G726-32/8000 

m=audio RTP/AVP 97 96 15 

To: A tag is added to the To header. 

Contact: Identifies the IP address or FQDN of the UE. 

SDP The SDP contains the subset of codecs supported by UE. It requests a confirmation of the 

QoS preconditions for establishing the session 

1 1 . Authorize QoS Resources 

P-CSCF authorizes the resources necessary for this session. 
12. 183 Session Progress (P-CSCF to I-CSCF) - see example in table 17.4.2.1-12 
P-CSCF forwards the 183 Session Progress response to I-CSCF. 

Table 17.4.2.1-12: 183 Session Progress (P-CSCF to I-CSCF) 

SIP/2.0 183 Session Progress 

Via; SIP/2. 0/UDP icscf 2_p . homel . net ; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf2.homel.net, SIP/2. 0/UDP icscf2_s.homel.net, SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) (ahomel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 ; ; aaa; bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; sip;pcscf2.visited2.net;lr, sip; icscf 2_p . homel .net; Ir, 
sip; Token (sip; scscf2 . homel .net;lr, sip;scscfl. homel .net; Ir, 
sip;pcscfl . homel .net; Ir ) @ homel .net; tokenized-by=homel .net 
P-As sorted- Identity; 
Privacy ; 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
From; 
To; 

Call-ID; 
CSeq; 
Require ; 
Contact ; 
RSeq; 

Content-Type ; 
Content-Length ; 

v= 
o = 
s= 
c= 

t = 
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P-CSCF restores the Via headers and Record-Route headers from the branch value in its Via. 
13. 183-Session-Progress (I-CSCF to S-CSCF) - see example in table 17.4.2.1-13 

I-CSCF determines the Via and Record-Route headers, and forwards the response to S-CSCF. 

Table 17.4.2.1-13: 183 Session Progress (I-CSCF to S-CSCF) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route; sip:pcscf 2 . visited2 . net; Ir, sip; icscf2_p. homel . net; Ir, sip; scscf 2 .homel . net; Ir, 
sip; scscfl . homel .net;lr, sip;pcscfl. homel .net; Ir 
P-Asserted- Identity ; 
Privacy ; 

P-Charging-Vector ; 
From; 
To; 

Call-ID; 
CSeq; 
Require : 
Contact : 
RSeq; 

Content-Type ; 
Content-Length ; 



14. 183 Session Progress (MT#lb to S-S) - see example in table 17.4.2.1-14 

S-CSCF forwards the 183 Session Progress response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 17.4.2.1-14: 183 Session Progress (MT#1b to S-S) 

SIP/2.0 183 Session Progress 

Via; SIP/2. 0/UDP icscf2_s .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; 

P-Asserted-Identity ; "John Smith" <sip ; user2_publicl@homel . net> 

Privacy; none 

P-Asserted-Identity; "John Smith" <tel ; +l-212-555-2222> 

Privacy; none 
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P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: See: 9ddl 

From: 

To: 

Call-ID: 

Require : 

CSeq: 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 



P-Charging- Vector: The S-CSCF adds its the identifier of its own network to the terminating Inter Operator 
Identifier (lOI) parameter of this header and puts back the originating lOI parameter. 

P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 

15. PRACK (S-S to MT#lb) - see example in table 17.4.2.1-15 

The originating endpoint sends a PRACK request containing the final SDP to be used in this session, via the 
S-CSCF to S-CSCF procedure, to S-CSCF. 

Table 17.4.2.1-15: PRACK (S-S to MT#1b) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .homel . net; Ir, sip: icscf2_p. homel . net; Ir, sip:pcscf 2 . visited2 . net; Ir 

From: sip:userl_publicl@homel . net; tag=171828 

To : sip:user2_publicl@home2 . net; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 128 PRACK 

Require: precondition 

Rack: 9021 127 INVITE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 
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16. PRACK (S-CSCF to I-CSCF) - see example in table 17.4.2.1-16 
S-CSCF forwards the PRACK request to I-CSCF. 

Table 17.4.2.1-16: PRACK (S-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: icscf2_s .homel . net; Ir sip:pcscf 2 . visited2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 
c= 

t = 



17. PRACK (I-CSCF to P-CSCF) - see example in table 17.4.2.1-17 

I-CSCF translates the Via headers in the PRACK request, and forwards the request to P-CSCF. 

Table 17.4.2.1-17: PRACK (I-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf2_p . homel . net ; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 
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Via: Translated to preserve configuration independence of the home network. 

18. PRACK (P-CSCF to UE) - see example in table 17.4.2.1-18 

P-CSCF forwards the PRACK request to UE. 

Table 17.4.2.1-18: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards : 65 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 

19. 200 OK (UE to P-CSCF) - see example in table 17.4.2.1-19 

UE acknowledges the PRACK request (18) with a 200 OK response. 

Table 17.4.2.1-19: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 
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20. 200 OK (P-CSCF to I-CSCF) - see example in table 17.4.2.1-20 
P-CSCF forwards the 200 OK response to I-CSCF. 

Table 17.4.2.1-20: 200 OK (P-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_p.homel . net; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c= 

t = 



Via: P-CSCF restores the Via headers from saved values, based on the token value in the branch 

parameter of its Via. 

21. 200 OK (I-CSCF to S-CSCF) - see example in table 17.4.2.1-21 

I-CSCF determines the Via and Record-Route headers, and forwards the 200 OK response to S-CSCF. 

Table 17.4.2.1-21 : 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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22. 200 OK (MT#lb to S-S) - see example in table 17.4.2.1-22 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 17.4.2.1-22: 200 OK (MT#1b to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type 

Content-Length : 



23. Resource Reservation 

UE initiates the reservation procedures for the resources needed for this session. 

24. UPDATE (S-S to MT#lb) - see example in table 17.4.2.1-24 

When the originating endpoint has completed its resource reservation, it sends the UPDATE request to S- 
CSCF, via the S-CSCF to S-CSCF procedures. 

Table 17.4.2.1-24: UPDATE (S-S to MT#1b) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .homel . net; Ir, sip: icscf2_p. homel . net; Ir, sip:pcscf 2 . visited2 . net; Ir 

From: sip : userl_publicl@homel . net ; tag=171828 

To : sip: user 2_publicl@home2 . net; tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 129 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=qos : success sendonly 

m=audio RTP/AVP 97 96 15 

25. UPDATE (S-CSCF to I-CSCF) - see example in table 17.4.2.1-25 
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S-CSCF forwards the UPDATE request to I-CSCF. 

Table 17.4.2.1-25: UPDATE (S-CSCF to I-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: icscf2_p. homel . net; Ir, sip:pcscf 2 . visited2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



26. UPDATE (I-CSCF to P-CSCF) - see example in table 17.4.2.1-26 

I-CSCF translates the Via headers in the UPDATE request, and forwards the request to P-CSCF. 

Table 17.4.2.1-26: UPDATE (I-CSCF to P-CSCF) 

UPDATE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP icscf2„p . homel . net ; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 

3 = 
C= 

t = 



Via: Translated to preserve configuration independence of the home network. 

Record-Route: Translated to preserve configuration independence of the home network. 
27. UPDATE (P-CSCF to UE) - see example in table 17.4.2.1-27 
P-CSCF forwards the UPDATE request to UE. 
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Table 17.4.2.1-27: UPDATE (P-CSCF to UE) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net;branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 

v= 
o = 
s = 

c= 

t = 



Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 



28. 200 OK (UE to P-CSCF) - see example in table 17.4.2.1-28 

UE acknowledges the UPDATE request (27) with a 200 OK response. 

Table 17.4.2.1-28: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=video RTP/AVP 99 

m=video RTP/AVP 99 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=audio RTP/AVP 97 96 15 

29. 200 OK (P-CSCF to I-CSCF) - see example in table 17.4.2.1-29 

P-CSCF forwards the 200 OK response to I-CSCF. 

Table 17.4.2.1-29: 200 OK (P-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_p.homel . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf2.homel.net;branch=z9hG4bK764z87. 1, SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net; tokenized-by=homel . net, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 
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Call-ID: 
CSeq: 

Content-type ; 
Content-Length : 



P-CSCF restores the Via headers from saved values, based on the token value in the branch parameter of its 
Via. 

30. 200 OK (I-CSCF to S-CSCF) - see example in table 17.4.2.1-30 

I-CSCF determines the Via and Record-Route headers, and forwards the 200 OK to S-CSCF 

Table 17.4.2.1-30: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .homel .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-type : 

Content-Length : 



31. 200 OK (MT#lb to S-S) - see example in table 17.4.2.1-31 

S-CSCF forwards the 200 OK response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 17.4.2.1-31 : 200 OK (MT#1b to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 
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CSeq: 

Content-type : 
Content-Length ; 



32. 180 Ringing (UE to P-CSCF) - see example in table 17.4.2.1-32 (related to 17.4.2.1-8) 

Before proceeding with session establishment, the UE waits for two events. First, the resource reservation 
initiated in step #23 must complete successfully. Second, the resource reservation initiated by the originating 
endpoint must complete successfully (which is indicated by message #27 received by UE). The UE may now 
immediately accept the session (and proceed with step #45), or alert the destination subscriber of an 
incoming session attempt; if the latter it indicates this to the calling party by a 180 Ringing provisional 
response sent to P-CSCF. 

Table 17.4.2.1-32: 180 Ringing (UE to P-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net;branch=z9hG4bK361k21 . 1 

From; 

To: sip ; user2_publicl@home2 . net ; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 9022 

Content-Length: 

33. 180 Ringing (P-CSCF to I-CSCF) - see example in table 17.4.2.1-33 

P-CSCF forwards the 180 Ringing response to I-CSCF. 

Table 17.4.2.1-33: 180 Ringing (P-CSCF to I-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_p . homel . net ; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf2.homel.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871y 12 . 1, 
SIP/2. 0/UDP scscfl.homel.net SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : sip:pcscf2.visited2.net;lr, sip: icscf 2_p . homel .net; Ir, 

sip: Token (sip: scscf2 . homel .net;lr, sip:scscfl. homel .net;lr, sip:pcscfl. homel .net; Ir ) 
(3 homel .net; tokenized-by=homel .net 

P-Charging-Vector : icid-value=1234bcd987 6e; icid- generated- at =[5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 
Content-Length : 



34. 180 Ringing (I-CSCF to S-CSCF) - see example in table 17.4.2.1-34 
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I-CSCF determines the Via and Record-Route headers, and forwards the 180 Ringing response to S-CSCF. 
Table 17.4.2.1-34: 180 Ringing (I-CSCF to S-CSCF) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . homel . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route: sip:pcscf 2 . visited2 . net; Ir, sip: icscf2_s .homel . net; Ir, sip: scscf2 .homel . net; Ir, 

sip: scscfl . homel .net;lr, sip:pcscfl. homel .net; Ir 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

Upon receipt of the 180, the S-CSCF stores the P-Charging- Vector information for this session. 

35. 180 Ringing (MT#lb to S-S) - see example in table 17.4.2.1-35 

S-CSCF forwards the 180 Ringing response to the originating endpoint, per the S-CSCF to S-CSCF 
procedure. 

Table 17.4.2.1-35: 180 Ringing (MT#1b to S-S) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Length : 

36. PRACK (S-S to MT#lb) - see example in table 17.4.2.1-36 

The originator acknowledges the 180 Ringing response (35) with a PRACK request. 

Table 17.4.2.1-36: PRACK (S-S to MT#1b) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .homel . net, sip: icscf2„p. homel . net; Ir, sip:pcscf 2 . visited2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 130 PRACK 

Raclt: 9022 127 INVITE 

Content-Length: 

37. PRACK (S-CSCF to I-CSCF) - see example in table 17.4.2.1-37 

S-CSCF forwards the PRACK request to I-CSCF. 

Table 17.4.2.1-37: PRACK (S-CSCF to I-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .homel .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 
SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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Max-Forwards: 67 

Route: sip: icscf2_s .homel . net; Ir, sip:pcscf2 . visitecl2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 



38. PRACK (I-CSCF to P-CSCF) - see example in table 17.4.2.1-38 

I-CSCF translates the Via headers in the PRACK request, and forwards the request to P-CSCF. 

Table 17.4.2.1-38: PRACK (I-CSCF to P-CSCF) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf2_p . homel . net;branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP scscfl .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

Via: Translated to preserve configuration independence of the home network. 

Record-Route: Translated to preserve configuration independence of the home network. 

39. PRACK (P-CSCF to UE) - see example in table 17.4.2.1-39 

P-CSCF forwards the PRACK request to UE. 

Table 17.4.2.1-39: PRACK (P-CSCF to UE) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards : 65 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 



Via: 



P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 
values. It inserts this as a branch value on its Via header. 



40. 200 OK (UE to P-CSCF) - see example in table 17.4.2.1-40 

UE acknowledges the PRACK request (39) with a 200 OK response. 

Table 17.4.2.1-40: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

41. 200 OK (P-CSCF to I-CSCF) - see example in table 17.4.2.1-41 
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P-CSCF forwards the 200 OK to I-CSCF. 

Table 17.4.2.1-41 : 200 OK (P-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2„p . homel . net ;branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf2.homel.net;branch=z9hG4bK7 64z87. 1, SIP/ 2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; token! zed-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

42. 200 OK (I-CSCF to S-CSCF) - see example in table 17.4.2.1-42 

I-CSCF determines the Via and Record-Route headers, and forwards the 200 OK response to S-CSCF. 

Table 17.4.2.1-42: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP pcscfl .homel . net ; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

43. 200 OK (MT#lb to S-S) - see example in table 17.4.2.1-43 

S-CSCF forwards the 200 OK to the session originator, per the S-CSCF to S-CSCF procedures. 

Table 17.4.2.1-43: 200 OK (MT#1b to S-S) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

44. 200 OK (UE to P-CSCF) - see example in table 17.4.2.1-44 (related to 17.4.2.1-8) 

When the called party answers, the UE sends a 200 OK final response to the INVITE request (8) to P-CSCF, 
and starts the media flow(s) for this session. 



Table 17.4.2.1-44: 200 OK (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call-ID: 

CSeq: 127 INVITE 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

Content-Length: 



45. 200 OK (P-CSCF to I-CSCF) - see example in table 17.4.2.1-45 



P-CSCF indicates the resources reserved for this session should now be committed, and sends the 200 OK 
final response to I-CSCF. 
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Table 17.4.2.1-45: 200 OK (P-CSCF to l-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_p . homel . net ; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, 
SIP/2. 0/UDP scscfl.homel.net, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) ghomel . net ; tokenized-by=homel . net, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

Record-Route ; sip;pcscf2.visited2.net;lr, sip; icscf 2_s . homel .net; Ir, 
sip: Token (sip; scscf2 . homel .net;lr, sip;scscfl. homel .net; Ir, 
sip;pcscfl . homel .net; Ir ) (3 homel .net; tokenized-by=homel .net 

P-Charging-Vector ; icid-value=1234bcd987 6e; icid- generated- at =[5555; ;f5f;e4e;d3d;c2c] ; 
ggsn=[5555; ;d6d;c7c;b8b;a9al ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=3 
From; 
To; 

Call-ID; 
CSeq; 
Contact ; 
Content-Length ; 

46. 200 OK (I-CSCF to S-CSCF) - see example in table 17.4.2.1-46 

I-CSCF determines the Via and Record-Route headers, and forwards the 200 OK response to S-CSCF. 

Table 17.4.2.1-46: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP scscf2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2„s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 ; ; aaa;bbb; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route; sip;pcscf 2 . visited2 . net; Ir, sip; icscf 2_p. homel . net; Ir, sip; iscscf 2 .homel . net; Ir, 
sip; scscfl . homel .net;lr, sip;pcscfl. homel .net; Ir 
P-Charging-Vector ; 
From; 
To; 

Call-ID; 
CSeq; 
Contact : 
Content-Length ; 

Upon receipt of the 200, the S-CSCF stores the P-Charging-Vector information for this session (unless 
already done if information received with the 180). 

47. 200 OK (MT#lb to S-S) - see example in table 17.4.2.1-47 

S-CSCF forwards the 200 OK final response along the signalling path back to the session originator, as per 
the S-CSCF to S-CSCF procedure. 

Table 17.4.2.1-47: 200 OK (MT#1b to S-S) 

SIP/2.0 200 OK 

Via; SIP/2. 0/UDP icscf 2_s .homel .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP pcscf 1 .homel . net;branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 

Record-Route ; 

From; 

To; 

Call-ID; 

CSeq; 

Contact ; 

Content-Length ; 

48. ACK (S-S to MT#lb) - see example in table 17.4.2.1-48 

The calling party responds to the 200 OK final response (47) with an ACK request which is sent to S-CSCF 
via the S-CSCF to S-CSCF procedure. 
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Table 17.4.2.1-48: ACK (S-S to MT#1b) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: sip: scscf 2 .homel . net; Ir; sip: icscf2_p. homel . net; Ir, sip:pcscf 2 . visited2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 127 ACK 

Content-Length: 

49. ACK (S-CSCF to I-CSCF) - see example in table 17.4.2.1-49 

S-CSCF forwards the ACK request to I-CSCF. 

Table 17.4.2.1-49: ACK (S-CSCF to I-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Route: sip: icscf2_s .homel . net; Ir, sip:pcscf 2 . visited2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

50. ACK (I-CSCF to P-CSCF) - see example in table 17.4.2.1-50 

I-CSCF forwards the ACK request to P-CSCF. 

Table 17.4.2.1-50: ACK (I-CSCF to P-CSCF) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf2„s . homel . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 2 .homel . net; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd) ; branch=z9hG4bKnashds7 
Route : sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Content-Length : 

Via: Translated to preserve configuration independence of the home network. 

51. ACK (P-CSCF to UE) - see example in table 17.4.2.1-51 

P-CSCF forwards the ACK request to UE. 

Table 17.4.2.1-51 : ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saved 

values. It inserts this as a branch value on its Via header. 
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1 7.4.2.2 UE-detected failure/resource failure (not provided) 

An example of this flow is not shown in the present document. 

17.4.2.3 Origination failure (not provided) 

An example of this flow is not shown in the present document. 

17.4.3 Not applicable 

Void. 

17.4.4 Not required 

Void. 

17.4.5 MT#1d 

17.4.5.1 (MT#1d) Mobile termination, roaming, with l-CSCF in home network 

providing configuration independence, terminating UE is busy, and not able 
or not willing to answer the call (M0#2, S-S#2 assumed) 

Figure 17.4.5.1-1 shows a termination procedure which applies to roaming subscribers when the home network operator 
does not desire to keep its internal configuration hidden from the visited network. The UE is located in a visited 
network, and determines the P-CSCF via the P-CSCF discovery procedure. During registration, the home network 
allocates the S-CSCF. 

When registration is complete, S-CSCF knows the name/address of P-CSCF and the UE Contact address, and P-CSCF 
obtains the name/address of the UE. 
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S-CSCF 



— 1. INVITE- 
-2. 100 Trying - 



l-CSCF(THIG) 



3. Service Control 
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-9. 486 Busy Here- 
10. ACK 



Figure 17.4.5.1-1: MT#1d 
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Procedure MT#ld is as follows: 

1 . INVITE (S-S to MT#ld) - see example in table 17.4.5.1-1 

The calling party sends the INVITE request, via one of the origination procedures and via one of the S-CSCF 
to S-CSCF procedures, to the S-CSCF for the terminating subscriber. 

Table 17.4.5.1-1 : INVITE (S-S to MT#1d) 

INVITE sip:scscf2. homel.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_p.homel . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Record-Route : sip:332b23.1@scscfl. homel .net, sip:431h23.1@pcscfl. homel .net 

Route : sip : +1-2 12-5 5 5-2222 @homel .net; user=phone 

Supported: lOOrel 

Remote-Party-ID: "John Doe" <tel : +l-212-555-llll>; privacy=of f ; screen=yes 

Anonymity: Off 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip:user2_publicl@home2 . net 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907165275 

m=audio 3456 RTP/AVP 97 3 96 

b=AS:25.4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

a=rtpmap:96 G726-32/8000 

a=qos :mandatory sendrecv 

2. 100 Trying (MT#ld to S-S) - see example in table 17.4.5.1-2 

S-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 17.4.5.1-2: 100 Trying (MT#1d to S-S) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . homel . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 .homel . net; branch=z9hG4bK4 31h23 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

3. Service Control 

S-CSCF validates the service profile, and performs any termination service control required for this 
subscriber. 

S-CSCF examines the media parameters, and removes any choices that the destination subscriber does not 
have authority to request. 

4. INVITE (S-CSCF to I-CSCF) - see example in table 17.4.5.1-4 

S-CSCF remembers (from the registration procedure) the UE Contact address and the next hop CSCF for this 
UE. It forwards the INVITE to the I-CSCF to perform the THIG functions. 
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Table 17.4.5.1-4: INVITE (S-CSCF to l-CSCF) 

INVITE sip:icscf2_p. homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
Route: sip:pcscf 2 . visited2 . net, sip: [5555 :: eee : fff: aaa:bbb] 

Record-Route : sip:764z87.1@scscf2. homel .net, sip:332b23.1@scscfl. homel .net, 
sip:431h23.1@pcscfl .homel . net 
Supported: 
Remote-Party-ID : 
Anonymity : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e661; ccf=[5555: :a55:b44:c33:d22]; 
ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: 8cc: 9dd] 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 

P-Called-Party-ID: <sip: +1-2 12-555-2222 ghomel .net; user=phone> 
Content-Type : 
Content-Length: (...) 



Route: Built from the Contact address stored at registration. 

P-Called-Party-ID: Includes the dialled URL with its parameters. 
Via:/Record-Route: S-CSCF adds itself in the Record-Route and Via headers. 
P-Charging-Function-Addresses: The S-CSCF passes this header to the I-CSCF for charging. 
5. INVITE (I-CSCF to P-CSCF) - see example in table 17.4.5.1-5 

I-CSCF translates the Via headers in the request, and forwards the INVITE request to P-CSCF. 

Table 17.4.5.1-5: INVITE (I-CSCF to P-CSCF) 

INVITE sip:pcscf2. visited2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_p . homel . net ; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP 
Token (scscf 2 . homel . net ; branch=z9hG4bK7 64z87 . 1, S IP /2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Route: sip: [5555: : eee : f f f : aaa:bbb] 

Record-Route : sip: a9012 . I@icscf2_p. homel . net, sip:Token(764z87.1@scscf2 .homel . net, 
sip: 332b23 . l@scscfl . homel .net), sip:431h23.1(?pcscfl. homel .net 
Supported: 
Remote-Party-ID : 
Anonymity : 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 

P-Called-Party-ID : 
Content-Type : 
Content-Length : 
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Via: Translated to preserve configuration independence of the home network. 

Record-Route: Translated to preserve configuration independence of the home network. 

6. 100 Trying (P-CSCF to I-CSCF) - see example in table 17.4.5.1-6 

P-CSCF responds to the INVITE request (5) with a 100 Trying provisional response. 

Table 17.4.5.1-6: 100 Trying (P-CSCF to I-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_p . homel . net ;branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP 
Token (scscf 2 . homel . net ; branch=z9hG4bK7 64z87 . 1, S IP /2. 0/UDP 

icscf 2„s .homel . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, S IP /2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

7. 100 Trying (I-CSCF to S-CSCF) - see example in table 17.4.5.1-7 

I-CSCF determines the Via header, and forwards the 100 Trying provisional response to S-CSCF. 

Table 17.4.5.1-7: 100 Trying (I-CSCF to S-CSCF) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .homel . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 
SIP/ 2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

8. INVITE (P-CSCF to UE) - see example in table 17.4.5.1-8 

P-CSCF extract the UE address from the Route header value and place it into the Request-URI,.and forwards 
the INVITE request to the UE. 

Table 17.4.5.1-8: INVITE (P-CSCF to UE) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

Media-Authorization: 0020000100100101706466322e76697369746564322e6e6574000c020133315331343363231 

Supported: 

Remote-Party-ID : 

Anonymity : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

P-Called-Party-ID : 

Content-Type : 

Content-Length : 
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P-CSCF removes the Record-Route headers, calculates the proper Route header to add to future requests, and 
saves that information without passing it to UE. The saved value of the Route header is: 

Route ; sip;a9012. l@icscf 2_p . homel .net, sip;Token(764z87.1@scscf2. homel .net, 
sip; 332b23 . l@scscfl . homel . net ) , 
sip: [5555: : aaa:bbb: ccc : ddd] 

Via: P-CSCF removes the Via headers, and generates a locally unique token to identify the saves 

values. It inserts this as a branch value on its Via header. 

Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy-Element 
generated by "pdf2.visited2.net" with credentials "31S1462r'. 

9. 486 Busy Here (UE to P-CSCF) - see example in table 17.4.5.1-9 

UE is contacted successfully but it is currently not willing or able to take additional sessions. The response 
MAY indicate a better time to call in the Retry-After header. 

Table 17.4.5.1-9: 486 Busy Here (UE to P-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: tel: +1-212-555-2222; tag=3 14 15 9 

Call-ID: 

CSeq: 

Contact: sip: [5555: : eee : f f f : aaa : bbb] 

Retry-After: 3600 

Content-Length: 

Retry-After: Indicates how long the caller can try again. 

10. ACK (P-CSCF to UE) - see example in table 17.4.5.1-10 

Upon receive the 486 response from the UE, P-CSCF sends ACK back to the UE. 

Table 17.4.5.1-10: ACK (P-CSCF to UE) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

1 1. 486 Busy Here (P-CSCF to I-CSCF) - see example in table 17,4.5.1-11 (related to table 17.4.5.1-9) 

P-CSCF forwards the 486 response to the I-CSCF. 

Table 17.4.5.1-11: 486 Busy Here (P-CSCF to I-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP icscf2_p . homel . net ; branch=z9hG4bKa9012 . 1, SIP/2. 0/UDP 
Token (scscf 2 . homel . net ; branch=z9hG4bK7 64z87 . 1, SIP/ 2. 0/UDP 
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icscf 2_s .homel . net;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, 

SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 

[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : sip:361k21.1@pcscf2.visited2.net, sip:a9012. l@icscf 2_p . homel .net, 

sip: Token (764z87.1@scscf2 .homel . net, sip:332b23.1@scscfl .homel . net, 

sip: 4 31h23 . ISpcscf 1 .homel . net) 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Retry-After: 
Content-Length : 

12. 486 Busy Here (I-CSCF to S-CSCF) - see example in table 17.4.5.1-12 

I-CSCF forwards the 486 response to the S-CSCF. 

Table 17.4.5.1-12: 486 Busy Here (I-CSCF to S-CSCF) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .homel . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP scscf 1 .homel . net ; branch=z9hG4bK332b23 . 1, 

SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK4 31h23. 1, SIP/ 2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : sip:361k21.1@pcscf2.visited2.net, sip:a9012. l@icscf 2_p . homel .net, 

sip: 764z87 . I@scscf2 . homel .net, sip:332b23.1@scscfl. homel .net, sip:431h23.1@pcscfl. homel .net 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Retry-After: 
Content-Length : 

13. ACK (S-CSCF to I-CSCF) - see example in table 17.4.5.1-13 

S-CSCF copies the Requet-URI and Route headers from the original INVITE request to ACK and send it to 
the P-CSCF via I-CSCF. 



Table 17.4.5.1-13: ACK (S-CSCF to I-CSCF) 

ACK: sip:icscf2_p. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . homel . net ; branch=z9hG4bK764z87 . 1 

Route : sip: 3 61k21 . I@pcscf2 . visited2 . net, sip: [5555: :eee:fff: aaa: bbb] 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

14. ACK (I-CSCF to P-CSCF) - see example in table 17.4.5.1-14 

I-CSCF forwards the ACK to the P-CSCF, P-CSCF checks the ACK and makes sure this is for a 4xx 
response, so P-CSCF will not forward it further down. 

Table 17.4.5.1-14: ACK (I-CSCF to P-CSCF) 

ACK: sip:pcscf2. visited2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_p . homel . net ; branch=z9hG4bKa9012 . 1@ SIP/2. 0/UDP 

Token (scscf 2 . homel . net ; branch=z9hG4bK7 64z87 . 1 
Route: sip: [5555: : eee : f f f : aaa:bbb] 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

15. Service Control 
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The S-CSCF validates the service profile and performs any service control required for this subscriber. 
16. 486 Busy Here (MT#ld to S-S) - see example in table 17.4.5.1-16 (related to table 17.4.5.1-12) 
S-CSCF forwards the 486 response to the originator, per the S-CSCF to S-CSCF procedure. 

Table 17.4.5.1-16: 486 Busy Here (MT#1d to S-S) 

SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP icscf 2_s .homel . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK4 31h23 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 

Retry-After: 3600 
Content-Length: 

17. ACK (S-S to MT#ld) - see example in table 17.4.5.1-17 
S-CSCF sends the ACK to the S-CSCF. 

Table 17.4.5.1-17: ACK (S-S to MT#1d) 

ACK sip:scscf2. homel. net SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net;branch=z9hG4bK332b23 . 1 

Route : sip : +1-2 12-5 5 5-2222 @homel .net; user=phone 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



1 7.5 Sample multimedia signalling flows: addition of further 
media streams 

17.5.1 Introduction 

See subclause 7.5.1. 

1 7.5.2 Sample multimecjia signalling flow - acJdition of further media 
originator and terminator are both roaming and operated by different 
networks 

Figure 17.5.2-1 shows a multimedia signalling flow for the addition of another media where the originator and 
terminator are both roaming and operated by different networks. Both networks are with 1-CSCF providing 
configuration independence. The UE has already established an IM CN session carrying voice and is generating an 
INVITE request to add video media to the already established IM session. 
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Figure 17.5.2-1 : Sample multimedia signalling flow - additional of further media with l-CSCF (THIG) 
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1. INVITE (UEl to P-CSCFl) - see example in table 17.5.2-1 

UE sends the Re-INVITE request, containing another media description in SDP, to the P-CSCF determined 
via the CSCF discovery mechanism. An example is contained in table 17.5.2-1. 

Table 17.5.2-1: INVITE (UEl to P-CSCFl) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Preferred-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq: 132 INVITE 

Require: precondition 

Supported: lOOrel 

Contact: sip: [5555: : aaa: bbb: ccc : ddd] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907166275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=video 9544 RTP/AVP 31 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:31 H261/90000 

Request-URI: Contains the keyed number from the user. This is specified by the UE as sipxkeyed 

number>@ ho mel.net. This is in accordance to standard IETF procedure for specifying 
dialled digits. 

Via: Contains the IP address or FQDN of the originating UE. 

P-Asserted-Identity: the user provides a hint about the identity to be used for this session. 

P-Access-Network-Info: the UE provides the access-type and access-info, related to the serving access network as 
specified in sub-clause 'Additional coding rules for P-access-network-info header', in 3GPP 
TS 24.229 [16]. 

From:/To:/Call-ID: Follow the recommendations of draft-ietf-sip-privacy [13], even though anonymity is not 
being requested for this session. 

Cseq: Is a random starting number. 

Contact: Is a SIP URL that contains the IP address or FQDN of the originating UE. 

2. 100 Trying (P-CSCFl to UEl) - see example in table 17.5.2-2 

P-CSCF responds to the INVITE request (1) with a 100 Trying provisional response. 

Table 17.5.2-2: 100 Trying (P-CSCFl to UEl) 

SIP/2.0 100 Trying 

via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



3. INVITE (P-CSCFl to I-CSCFla) - see example in table 17.5.2-3 

P-CSCFl forwards the INVITE to the next hop name/address, as determined from previous response 
messages. 

Table 17.5.2-3: INVITE (P-CSCFl to l-CSCF1a) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : sip : icscf l_p . homel .net;lr, sip:token(sip:scscfl. homel .net; Ir, 

sip : icscf l_s . homel .net; Ir ) @ homel .net; tokenized-by=homel .net, sip : icscf 2__s . home 2 .net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 . net ; Ir ) @ home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length: (...) 



Route: 



P-CSCF remembers (from the previous response messages) the request routing for this UE. This 
becomes a Route header in the request. 



4. INVITE (I-CSCFla to S-CSCFl) - see example in table 17.5.2-4 

I-CSCFla performs the THIG function and forwards the invite to S-CSCFl. 

Table 17.5.2-4: INVITE (I-CSCFla to S-CSCFl) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: sip: scscfl .homel . net; Ir, sip: icscf l_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip:token (sip: scscf2 . home 2 . net ; Ir, sip : icscf 2_p . home 2 .net; Ir ) (3home2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 
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P-Asserted-Identity : 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy ; 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length : 

v= 
o = 
s = 



5. 100 Trying (S-CSCFl to I-CSCFla) - see example in table 17.5.2-5 

S-CSCFl sends the 100 Trying provisional response to P-CSCFl through I-CSCFla. 

Table 17.5.2-5: 100 Trying (S-CSCFl to I-CSCFla) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

6. 100 Trying (I-CSCFla to P-CSCFl) - see example in table 17.5.2-6 

1-CSCFla forwards the 100 Trying provisional response to P-CSCFl. 

Table 17.5.2-6: 100 Trying (I-CSCFla to P-CSCFl) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

7. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 
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8. INVITE (S-CSCFl to I-CSCFlb) - see example in table 17.5.2-8 

S-CSCFl recognizes that this invite applies to an existing session. It therefore forwards the INVITE along 
the existing path to I-CSCFlb. 

Table 17.5.2-8: INVITE (S-CSCFl to I-CSCFlb) 

INVITE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : sip : icscf l_s . homel .net;lr, sip: icscf 2_s . home 2 .net;lr, sip:token(sip:scscf2. home 2 .net; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 

P -Asserted- Identity: 

Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel . net 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555::lff:2ee:3dd:4cc]; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Content-Type : 

Content-Length: (...) 

v= 
o = 
s = 
c = 

t = 



a= 
a= 

9. INVITE (I-CSCFlb to I-CSCF2a) - see example in table 17.5.2-9 

I-CSCFlb forwards the INVITE request to the next hop I-CSCF2a and performs the THIG function. 

Table 17.5.2-9: INVITE (I-CSCFlb to l-CSCF2a) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s . homel . net ;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l„p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: && 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:scscf2. home 2 .net; Ir, 

sip : icscf 2_p . home 2 . net ; Ir ) @ home 2 .net; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 
P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
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Contact : 
Content-Type : 
Content-Length ; 



10. INVITE (I-CSCF2a to S-CSCF2) - see example in table 17.5.2-10 

I-CSCF2a forwards the INVITE request to S-CSCF2. 

Table 17.5.2-10: INVITE (l-CSCF2a to S-CSCF2) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p.homel . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 

Route: sip: scscf 2 .home2 . net; Ir, sip: icscf 2__p.home2 . net; Ir, sip:pcscf 2 . visited2 . net; ir 
P -As sorted- Identity: 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length : 
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1 1. 100 Trying (S-CSCF2 to I-CSCF2a) - see example in table 17.5.2-11 

S-CSCF2 sends a 100 Trying provisional response back to S-CSCFl through I-CSCF2a. 

Table 17.5.2-11 : 100 Trying (S-CSCF2 to l-CSCF2a) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p.homel . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/ 2. 0/UDP, SIP/ 2. 0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

12. 100 Trying (I-CSCF2a to I-CSCFlb) - see example in table 17.5.2-12 

I-CSCF2a forwards a 100 Trying provisional response to the upstream next hop I-CSCFlb. 

Table 17.5.2-12: 100 Trying (l-CSCF2a to I-CSCFlb) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP, SIP/ 2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

13. 100 Trying (I-CSCFlb to S-CSCFl) - see example in table 17,5.2-13 
I-CSCF forwards a 100 Trying provisional response to the S-CSCFl. 

Table 17.5.2-13: 100 Trying (I-CSCFlb to S-CSCFl) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

14. Evaluation of initial filter criterias 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criterias. 

15. INVITE (S-CSCF2 to I-CSCF2b) - see example in table 17.5.2-15 

S-CSCF2 recognizes that this invite applies to an existing session. It therefore forwards the INVITE along 
the existing path to l-CSCF2b. 

Table 17.5.2-15: INVITE (S-CSCF2 to l-CSCF2b) 

INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 

SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscf l_p. homel . net ; branch=z9hG4bK351g4 5 . 1) @homel . net ; tokenized-by=homel .net, SIP/2 . 0/UDP 
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pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 . 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards ; 64 

Route; sip; icscf 2_p.home2 . net; Ir, sip;pcscf2 . visited2 . net; Ir 
P -Asserted- Identity ; 
Privacy ; 

P-Charging-Vector ; icid-value=1234bcd9876e; icid-generated-at= [5555 ; ; f 5f ; e4e ; d3d; c2c] 
P-Charging-Funct ion-Addresses; ccf=[5555; ;b99;c88;d7 7;e66]; ccf=[5555; ; a55 ; b4 4 ; c33 ; d22 ] ; 
ecf=[5555; ; If f ; 2ee ; 3dd; 4ccl ; ecf=[5555; ; 6aa; 7bb; 8cc ; 9dd] 
From; 
To; 

Call-ID; 
Cseq; 
Require ; 
Supported; 
Contact ; 
Content-Type ; 
Content-Length; (...) 



16. INVITE (I-CSCF2b to P-CSCF2) - see example in table 17.5.2-16 

I-CSCF2b performs the THIG function and forwards the INVITE request to P-CSCF2. 

Table 17.5.2-16: INVITE (I-CSCF2 to P-CSCF2) 

INVITE sip; [5555; ;eee;fff;aaa;bbb] SIP/2.0 

Via; SIP/2. 0/UDP icscf 2_p . home2 . net ; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf2.home2.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1) @home2 . net; tokenized-by=home2 . net, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
Max-Forwards ; 63 

Route ; sip;pcscf2.visited2.net;lr 
P -Asserted- Identity ; 
Privacy ; 

P-Charging-Vector ; 
From; 
To; 

Call-ID; 
Cseq; 
Require ; 
Supported; 
Contact ; 
Content-Type ; 
Content-Length ; 

v= 
o = 
s = 
c = 

t = 
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17. 100 Trying (P-CSCF2 to I-CSCF2b) - see example in table 17.5.2-17 

P-CSCF2 sends a 100 Trying provisional response back to S-CSCF2 through I-CSCF2b. 

Table 17.5.2-17: 100 Trying (P-CSCF2 to l-CSCF2b) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_p.home2 . net; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1) @home2 . net; tokenized-by=home2 . net, SIP/ 2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

18. 100 Trying (I-CSCF2b to S-CSCF2) - see example in table 17,5.2-18 

I-CSCF2b forwards a 100 Trying provisional response back to S-CSCF2. 

Table 17.5.2-18: 100 Trying (l-CSCF2b to S-CSCF2) 

SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . home 1 . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net ; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

19. INVITE (P-CSCF2 to UE2) - see example in table 17.5.2-19 

P-CSCF determines the UE address from the value of the Request-URI (which was previously returned by P- 
CSCF as a contact header value in the registration procedure), and forwards the INVITE request to the UE. 



Table 17.5.2-19: INVITE (P-CSCF2 to UE2) 



INVITE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

Max-Forwards: 62 

P-Media-Authorization: 0020000100100101706466322e76697369746564322e6e6574000c020133315331343363233 

P -Asserted- Identity : 

Privacy : 

From: 

To: 

Call-ID: 
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Cseq: 
Require : 
Supported: 
Contact : 
Content-Type : 
Content-Length ; 



P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdf2.visited2.net" with credentials "31S14623". 

20. 100 Trying (UE2 to P-CSCF2) - see example in table 17.5.2-20 

UE2 sends a 100 Trying provisional response back to P-CSCF2. 

Table 17.5.2-20: 100 Trying (UE2 to P-CSCF2) 

SIP/2.0 100 Trying 

Via: pcscf2.visited2.net;branch=z9hG4bKert23.8 SIP/2. 0/UDP 

From: 

To: 

Call-ID: 

CSeq: 



21. 183 Session Progress (UE2 to P-CSCF2) - see example in table 17.5.2-21 

The media stream capabilities of the destination are returned along the signalling path, in a 183 Session 
Progress provisional response. 

Table 17.5.2-21 : 183 Session Progress response (UE2 to P-CSCF2) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Preferred-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

RSeq: 9022 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907166275 

m=audio 6544 RTP/AVP 97 
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b=AS:25.4 3 

a=curr;qos local sendrecv 

a=curr;qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=video 7544 RTP/AVP 31 

b=AS:54. 6 

a=curr;qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:31 H261/90000 



22. Authorize QoS Resources 

P-CSCF2 authorizes the resources necessary for this new media. 
23. 183 Session Progress (P-CSCF2 to I-CSCF2b) - see example in table 17.5.2-23 

P-CSCF forwards the 183 Session Progress response to P-CSCF. 

Table 17.5.2-23: 183 Session Progress (P-CSCF2 to l-CSCF2b) 



SIP/2. O/UDP token (SIP/2. 0/UDP 
SIP/2. 0/UDP 

SIP/2. O/UDP 



SIP/2.0 183 Session Progress 

Via: SIP/2. O/UDP icscf 2„p . home2 . net ; branch=z9hG4bK556u87 . 1 
scscf 2 .home2 . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .O/UDP 

icscf 2_s . home 2 .net; branch=z9hG4bK871yl2 . 1 ) @ home 2 .net; tokenized-by=home2 . net ^ 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. O/UDP token (SIP/ 2. O/UDP 
scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .O/UDP 

icscf l_p . homel .net; branch=z9hG4bK351g45 . 1 ) (^homel .net; tokenized-by=homel .net, 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. O/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
P-Asserted-Identity: "John Smith" <tel : +l-212-555-2222> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



24. 183 Session Progress (I-CSCF2b to S-CSCF2) - see example in table 17.5.2-24 
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I-CSCF2b forwards the 183 Session Progress response to S-CSCF2. 

Table 17.5.2-24: 183 Session Progress (l-CSCF2b to S-CSCF2) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1) @homel . net ; tokenized-by=homel . net , S IP /2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
P -Asserted- Identity: 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy : 

P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



25. 183 Session Progress (S-CSCF2 to I-CSCF2a) - see example in table 17.5.2-25 
S-CSCF2 forwards the 183 Session Progress response to I-CSCF2a. 

Table 17.5.2-25: 183 Session Progress (S-CSCF2 to l-CSCF2a) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
P-Asserted- Identity: 
Privacy : 

P-Charging-Vector : icid-value = 1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 
ioi=homel .net; term-ioi=home2 .net 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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26. 183 Session Progress (I-CSCF2a to I-CSCFlb) - see example in table 17.5.2-26 

I-CSCF2a forwards the 183 Session Progress response to I-CSCFlb. 

Table 17.5.2-26: 183 Session Progress (l-CSCF2a to I-CSCFlb) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
P -Asserted- Identity : 
Privacy ; 

P-Charging-Vector ; 
From; 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



27. 183 Session Progress (I-CSCFlb to S-CSCFl) - see example in table 17.5.2-27 
I-CSCFlb forwards the 183 Session Progress response to the S-CSCFl. 
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Table 17.5.2-27: 183 Session Progress (l-CSCF1b to S-CSCF1) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P -Asserted- Identity: 

Privacy : 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 



28. 183 Session Progress (S-CSCFl to I-CSCFla) - see example in table 17.5.2-28 
S-CSCFl forwards the 183 Session Progress response to I-CSCFla. 

Table 17.5.2-28: 183 Session Progress (S-CSCFl to I-CSCFla) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
P -Asserted- Identity : 
Privacy : 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 
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29. 183 Session Progress (I-CSCFla to P-CSCFl) - see example in table 17.5.2-29 

I-CSCFla forwards the 183 Session Progress response to P-CSCFl. 

Table 17.5.2-29: 183 Session Progress (I-CSCFla to P-CSCFl) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb ; ccc : ddd] ; branch=z9hG4bKnashds7 
P-Asserted- Identity; 
Privacy : 

P-Charging-Vector : 
From; 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



30. Authorize QoS Resources 

P-CSCFl authorizes the resources necessary for this new media. 
31. 183 Session Progress (P-CSCFl to UEl) - see example in table 17.5.2-31 

P-CSCFl forwards the 183 Session Progress response to the originating endpoint. 

Table 17.5.2-31: 183 Session Progress (P-CSCFl to UEl) 

SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Media-Authorization: 0020000100100101706466312e76697369746564312e6e6574000c02013942563330373400 

P -Asserted- Identity : 

Privacy : 

From: 
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To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
RSeq: 

Content-Type : 
Content-Length : 



P-Media-Authorization: A P-CSCF generated authorization token. This particular example shows a Policy- 
Element generated by "pdfl.visitedl.net" with credentials "9BV3074". 

32. PRACK (UEl to P-CSCFl) - see example in table 17.5.2-32 

The originator decides the final set of media streams for this media addition, and sends the Final SDP to P- 
CSCFl. 

Table 17.5.2-32: PRACK (UEl to P-CSCFl) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip : user2_publicl@home2 . net ; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 133 PRACK 

Require: precondition 

Rack: 9022 132 Invite 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907166275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=video 9544 RTP/AVP 31 

b=AS:54. 6 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:31 H261/90000 
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33. PRACK (P-CSCFl to I-CSCFla) - see example in table 17.5.2-33 

The PRACK request is forwarded through this I-CSCF to the S-CSCF. 

Table 17.5.2-33: PRACK (P-CSCFl to l-CSCF1a) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : sip : icscf l_p . homel .net;lr, sip:token(sip:scscfl. homel .net; Ir, 

sip : icscf l_s . homel .net; Ir ) @ homel .net; tokenized-by=homel .net, sip : icscf 2_s . home 2 .net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



34. PRACK (I-CSCFla to S-CSCFl) - see example in table 17,5.2-34 

The PRACK request is forwarded through this I-CSCFla to the S-CSCFl. 

Table 17.5.2-34: PRACK (I-CSCFla to S-CSCFl) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: sip: scscfl .homel . net; Ir, sip: icscf l_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) (3 home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c= 
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35. PRACK (S-CSCFl to I-CSCFlb) - see example in table 17.5.2-35 
S-CSCFl forwards the PRACK request to I-CSCFlb. 

Table 17.5.2-35: PRACK (S-CSCFl to I-CSCFlb) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: icscfl_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net. 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



sip:token (sip: scscf2 . home 2 .net; Ir, 
sip:pcscf2 .visited2 . net; Ir 



36. PRACK (I-CSCFlb to I-CSCF2a) - see example in table 17.5.2-36 

I-CSCFlb forwards the PRACK request to I-CSCF2a. 



Table 17.5.2-36: PRACK (I-CSCFlb to l-CSCF2a) 



PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
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Route : sip: icscf2_s .home 2 . net; Ir, sip: token (sip:scscf2 .home 2 . net; Ir, 

sip : icscf 2_p .home 2 .net; Ir ) @ home 2 .net; tokenizecl-by=home2 .net, sip:pcscf2.visitecl2.net;lr 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Rack: 

Content-Type : 

Content-Length : 



37. PRACK (I-CSCF2a to S-CSCF2) - see example in table 17.5.2-37 
I-CSCF2a forwards the PRACK request to S-CSCF2. 

Table 17.5.2-37: PRACK (l-CSCF2a to S-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 

Route: sip: scscf 2 .home2 . net; Ir, sip: icscf 2_p.home2 . net; Ir, sip:pcscf 2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 
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38. PRACK (S-CSCF2 to I-CSCF2b) - see example in table 17.5.2-38 

S-CSCF2 forwards the PRACK request to I-CSCF2b. 

Table 17.5.2-38: PRACK (S-CSCF2 to l-CSCF2b) 

PRACK sip: [5555:eee:fff :aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 64 

Route: sip: icscf 2_p.home2 . net; Ir, sip:pcscf 2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 



39. PRACK (I-CSCF2b to P-CSCF2) - see example in table 17.5.2-39 

I-CSCFlb forwards the PRACK request to P-CSCF2. 

Table 17.5.2-39: PRACK (l-CSCF2b to P-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_p . home2 . net ;branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 2 .home2 . net; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1) @home2 . net; tokenized-by=home2 . net, S IP /2. 0/UDP 
icscf l_s .homel . net; branch=z9hG4bK312a32 .1, SIP/2 .0/UDP token (SIP /2 .0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 63 

Route : sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Rack: 

Content-Type : 
Content-Length : 
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40. PRACK (P-CSCF2 to UE2) - see example in table 17.5.2-40 
P-CSCF2 and forwards the PRACK request to the UE2. 

Table 17.5.2-40: PRACK (P-CSCF2 to UE2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

Max-Forwards : 62 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Content-Type : 

Content-Length : 



41. 200 OK (UE2 to P-CSCF2) - see example in table 17.5.2-41 

UE2 acknowledges the PRACK request with a 200 OK response. 

Table 17.5.2-41 : 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 133 Prack 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 
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o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=907166275 

m=audio 6544 RTP/AVP 97 

b=AS:25.4 3 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des;qos none remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=video 7544 RTP/AVP 31 

b=AS:54. 6 

a=curr:qos local none 

a=curr;qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=conf;qos remote sendrecv 

a=rtpmap:31 H261/90000 



42. Resource Reservation 

After determining the final set of media streams for this additional media, UE2 initiates the reservation 
procedures for the additional resources needed for this new media. 

43. 200 OK (P-CSCF2 to I-CSCF2b) - see example in table 17.5.2-43 

P-CSCF2 forwards the 200 OK response to I-CSCF2b. 



Table 17.5.2-43: 200 OK (P-CSCF2 to l-CSCF2b) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_p . home2 . net ; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf2.home2.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net; tokenized-by=home2 . net, SIP/ 2. 0/UDP 
icscfl_s. home 1. net ;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



44. 200 OK (I-CSCF2b to S-CSCF2) - see example in table 17.5.2-44 
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I-CSCF2b forwards the 200 OK response to S-CSCF2. 

Table 17.5.2-44: 200 OK (l-CSCF2b to S-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1) @homel . net ; tokenized-by=homel . net , S IP /2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



a= 
a= 

45. 200 OK (S-CSCF2 to I-CSCF2a) - see example in table 17.5.2-45 

S-CSCF2 forwards the 200 OK response to I-CSCF2a. 

Table 17.5.2-45: 200 OK (S-CSCF2 to l-CSCF2a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s. homel. net ;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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46. 200 OK (I-CSCF2a to I-CSCFlb) - see example in table 17.5.2-46 

I-CSCF2a forwards the 200 OK response to I-CSCFlb. 

Table 17.5.2-46: 200 OK (l-CSCF2a to I-CSCFlb) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



47. 200 OK (I-CSCFlb to S-CSCFl) - see example in table 17.5.2-47 
S-CSCF forwards the 200 OK response to S-CSCFl. 

Table 17.5.2-47: 200 OK (I-CSCFlb to S-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK24 Of 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



667 



ETSI TS 124 228 V5.3.0 (2002-12) 



48. 200 OK (S-CSCFl to I-CSCFla) - see example in table 17.5.2-48 
S-CSCFl forwards the 200 OK response to I-CSCFla. 

Table 17.5.2-48: 200 OK (S-CSCFl to I-CSCFla) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p.homel . net; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34. 1, SIP/2. 0/UDP 
[5555 ; : aaa ; bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



49. 200 OK (I-CSCFla to P-CSCFl) - see example in table 17.5.2-49 

I-CSCFl forwards the 200 OK response to P-CSCFl. 

Table 17.5.2-49: 200 OK (I-CSCFla to P-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 
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50. 200 OK (P-CSCFl to UEl) - see example in table 17.5.2-50 

P-CSCFl forwards the 200 OK response to the originator. 

Table 17.5.2-50: 200 OK (P-CSCFl to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From; 

To: 

Call-ID: 

CSeq: 

Content=Type : 

Content-Length : 



5 1 . Resource Reservation 

After determining the final set of media streams for this additional media, UEl initiates the reservation 
procedures for the additional resources needed for this new media. 

52. UPDATE (UEl to P-CSCFl) - see example in table 17.5.2-52 

When the resource reservation is completed, UE sends the UPDATE request to the terminating endpoint, via 
the signalling path established by the INVITE request. 

Table 17.5.2-52: UPDATE (UEl to P-CSCFl) 

UPDATE sip: [5555 :: eee : fff : aaa : bbb] SIP/2.0 
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Via: SIP/2. 0/UDP [5555 : : aaa:bbb: ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards; 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To; sip ; user2_publicl@home2 . net ; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 134 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=907166275 

m=audio 3456 RTP/AVP 97 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; maxframes=2 

m=video 9544 RTP/AVP 31 

b=AS:54. 6 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:31 H261/90000 

53. UPDATE (P-CSCFl to I-CSCFla) - see example in table 17.5.2-53 

The UPDATE request is forwarded through this P-CSCFl to the I-CSCFla. 

Table 17.5.2-53: UPDATE (P-CSCFl to I-CSCFla) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : sip : icscf l_p . homel .net;lr, sip:token(sip:scscfl. homel .net; Ir, 

sip : icscf l_s . homel .net; Ir ) @ homel . net ; tokenized-by=homel .net, sip : icscf 2_s . home 2 .net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) (3 home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : icid-value=1234bcd987 6e; ic id-gene rat ed-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :4b4:3c3:2d2: lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=l 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
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54. UPDATE (I-CSCFla to S-CSCFl) - see example in table 17.5.2-54 

The UPDATE request is forwarded through this I-CSCFla to the S-CSCFl. 

Table 17.5.2-54: UPDATE (I-CSCFla to S-CSCFl) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: sip: scscfl .homel . net; Ir, sip: icscf l_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 



55. UPDATE (S-CSCFl to I-CSCFlb) - see example in table 17.5.2-55 
S-CSCFl forwards the UPDATE request to I-CSCFlb. 

Table 17.5.2-55: UPDATE (S-CSCFl to I-CSCFlb) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : sip : icscf l„s . homel .net;lr, sip: icscf 2_s . home 2 .net;lr, sip:token(sip:scscf2. home 2 .net; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] ; orig- 

ioi=homel .net; term-ioi=home2 .net 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 
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56. UPDATE (I-CSCFlb to I-CSCF2a) - see example in table 17.5.2-56 

I-CSCFlb forwards the UPDATE request, to I-CSCF2a. 

Table 17.5.2-56: UPDATE (l-CSCF1b to l-CSCF2a) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:scscf2. home 2 .net; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



57. UPDATE (I-CSCF2a to S-CSCF2) - see example in table 17.5.2-57 
I-CSCF2a forwards the UPDATE request to S-CSCF2. 

Table 17.5.2-57: UPDATE (l-CSCF2a to S-CSCF2) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/2. 0/UDP 
scscfl .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 

Route: sip: scscf 2 .home2 . net; Ir, sip : icscf 2_p . home2 . net ; Ir, sip : pcscf 2 . visited2 . net ; Ir 
P-Charging-Vector : 
From: 
To: 
Call-ID: 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 



672 



ETSI TS 124 228 V5.3.0 (2002-12) 



Cseq: 

Content-Type : 
Content-Length ; 



58. UPDATE (S-CSCF2 to I-CSCF2b) - see example in table 17.5.2-58 

S-CSCF2 forwards the UPDATE request to I-CSCF2b. 

Table 17.5.2-58: UPDATE (S-CSCF2 to l-CSCF2b) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 64 

Route: sip: icscf 2_p.home2 . net; Ir, sip:pcscf 2 . visited2 . net 

P-Charging-Vector : icid-value=1234bcd9876e; icid-generated-at= [5555 : : f 5f : e4e : d3d: c2c] 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 



59. UPDATE (I-CSCF2b to P-CSCF2) - see example in table 17.5.2-59 

I-CSCF2b forwards the UPDATE request to P-CSCF2. 
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Table 17.5.2-59: UPDATE (l-CSCF2b to P-CSCF2) 

UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_p.home2 . net; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf2 .home2 . net; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net; tokenized-by=home2 . net, S IP /2. 0/UDP 
icscfl_s. home 1. net ;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

icscf l„p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 63 

Route : sip:pcscf2.visited2.net;lr 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o = 
s = 
c = 

t = 



a= 
a= 
a= 
a= 

60. UPDATE (P-CSCF2 to UE2) - see example in table 17.5.2-60 

P-CSCF2 determines the UE address from the value of the Request-URI and forwards the UPDATE request 
to the UE2. 



Table 17.5.2-60: UPDATE (P-CSCF2 to UE2) 



UPDATE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net;branch=z9hG4bK361k21 . 1 

Max-Forwards : 62 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 
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61. 200 OK (UE2 to P-CSCF2) - see example in table 17.5.2-61 

UE2 acknowledges the UPDATE request with a 200 OK response. 

Table 17.5.2-61 : 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From; 

To: 

Call-ID: 

CSeq: 134 UPDATE 

Content-Length: 

62. 200 OK (P-CSCF2 to I-CSCF2b) - see example in table 17.5.2-62 

Table 17.5.2-62: 200 OK (P-CSCF2 to l-CSCF2b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_p . home2 . net ; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf2.home2.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net ; tokenized-by=home2 . net , SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP token (SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

63. 200 OK (I-CSCF2b to S-CSCF2) - see example in table 17.5.2-63 

Table 17.5.2-63: 200 OK (l-CSCF2b to S-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1) @homel . net ; tokenized-by=homel . net , S IP /2. 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

64. 200 OK (S-CSCF2 to I-CSCF2a) - see example in table 17.5.2-64 

Table 17.5.2-64: 200 OK (S-CSCF2 to l-CSCF2a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
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To: 

Call-ID: 
CSeq: 
Content-Length : 



65. 200 OK (I-CSCF2a to I-CSCFlb) - see example in table 17.5.2-65 

Table 17.5.2-65: 200 OK (l-CSCF2a to l-CSCF1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

66. 200 OK (I-CSCFlb to S-CSCFl) - see example in table 17.5.2-66 

Table 17.5.2-66: 200 OK (I-CSCFlb to S-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

67. 200 OK (S-CSCFl to I-CSCFla) - see example in table 17.5.2-67 

Table 17.5.2-67: 200 OK (S-CSCFl to l-CSCF1a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

68. 200 OK (I-CSCFla to P-CSCFl) - see example in table 17.5.2-68 

Table 17.5.2-68: 200 OK (I-CSCFla to P-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 



69. 200 OK (P-CSCFl to UEl) - see example in table 17.5.2-69 

Table 17.5.2-69: 200 OK (P-CSCFl to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 
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From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



70. Alerting 



UE2 may optionally delay the session establishment in order to alert the subscriber to the incoming additional 
media. 

71. 180 Ringing (UE2 to P-CSCF2) - see example in table 17.5.2-71 



If UE2 performs alerting, it sends a ringing indication to the originator via the signalling path. The response 
is sent first to P-CSCF2. 



Table 17.5.2-71 : 180 Ringing (UE2 to P-CSCF2) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 132 INVITE 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

Rseq: 9023 

Content-Length: 



72. 180 Ringing (P-CSCF2 to I-CSCF2b) - see example in table 17.5.2-72 



Table 17.5.2-72: 180 Ringing (P-CSCF2 to l-CSCF2b) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_p . home2 . net ;branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf2.home2.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net ; tokenized-by=home2 . net , SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net ; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : icid-value=1234bcd987 6e; ic id-gene rat ed-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=l 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Rseq: 
Content-Length : 



73. 180 Ringing (I-CSCF2b to S-CSCF2) - see example in table 17.5.2-73 



Table 17.5.2-73: 180 Ringing (l-CSCF2b to S-CSCF2) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1) @homel . net ; tokenized-by=homel . net , S IP /2. 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
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Rseq: 

Content-Length : 



74. 180 Ringing (S-CSCF2 to I-CSCF2a) - see example in table 17.5.2-74 



Table 17.5.2-74: 180 Ringing (S-CSCF2 to l-CSCF2a) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc: ddd] ;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Rseq: 
Content-Length : 

75. 180 Ringing (I-CSCF2a to I-CSCFlb) - see example in table 17.5.2-75 

Table 17.5.2-75: 180 Ringing (l-CSCF2a to l-CSCF1b) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf l_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Rseq: 
Contact : 
Content-Length : 

76. 180 Ringing (I-CSCFlb to S-CSCFl) - see example in table 17.5.2-76 

Table 17.5.2-76: 180 Ringing (I-CSCFlb to S-CSCFl) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

S IP /2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Rseq: 

Content-Length : 

77. 180 Ringing (S-CSCFl to I-CSCFla) - see example in table 17.5.2-77 

Table 17.5.2-77: 180 Ringing (S-CSCFl to l-CSCF1a) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP icscf l„p. homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Rseq: 
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Content-Length: 

78. 180 Ringing (I-CSCFla to P-CSCFl) - see example in table 17.5.2-78 

Table 17.5.2-78: 180 Ringing (l-CSCF1a to P-CSCFl) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Rseq: 
Content-Length : 

79. 180 Ringing (P-CSCFl to UEl) - see example in table 17.5.2-79 

Table 17.5.2-79: 180 Ringing (P-CSCFl to UEl) 

SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 

80. Ringback 

UE#1 indicates to the originator that the media addition is being delayed due to alerting. Typically this 
involves playing a ringback sequence. 

81. PRACK (UEl to P-CSCFl) - see example in table 17.5.2-81 

The originator sends ACK to the terminator for the Ringing response. 

Table 17.5.2-81: PRACK (UEl to P-CSCFl) 

PRACK sip: [5555 :: eee : fff : aaa : bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Networli-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip:user2_publicl@home2 . net; tag=314159 

Call- ID: Cb03a0s0 9a2sdf gilt j 4 90333 

Cseq: 135 PRACK 

Raclc: 9023 132 Invite 

Content-Length : 

82. PRACK (P-CSCFl to I-CSCFla) - see example in table 17.5.2-82 

The PRACK request is forwarded through this I-CSCF Ito the S-CSCF. 

Table 17.5.2-82: PRACK (P-CSCFl to I-CSCFla) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : sip : icscf l_p . homel .net;lr, sip:to]cen(sip:scscfl. homel .net; Ir, 

sip : icscf l_s . homel .net; Ir ) @ homel .net; to]cenized-by=homel .net, sip : icscf 2_s . home 2 .net; Ir, 
sip:to]cen (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) @ home 2 .net; to]cenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Networlt-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 
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Call-ID: 
Cseq: 
Rack: 
Content-Length : 



83. PRACK (I-CSCFla to S-CSCFl) - see example in table 17.5.2-83 

The PRACK request is forwarded through this I-CSCFla to the S-CSCFl. 

Table 17.5.2-83: PRACK (I-CSCFla to S-CSCFl) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: sip: scscfl .homel . net; Ir, sip: icscf l_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

84. PRACK (S-CSCFl to I-CSCFlb) - see example in table 17.5.2-84 

S-CSCFl forwards the PRACK request to 1-CSCFlb. 

Table 17.5.2-84: PRACK (S-CSCFl to l-CSCF1b) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 .1, SIP/2 . 0/UDP pcscf 1 .visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: sip: icscf l_shomel . net; Ir, sip: icscf 2_s .home2 . net; Ir, sip: token (sip: scscf 2 .home2 . net; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) (3home2 . net ; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 

From: 

To: 

Call-ID: 

Cseq: 

Rack: 

Content-Length : 

85. PRACK (I-CSCFlb to I-CSCF2a) - see example in table 17.5.2-85 

1-CSCFlb forwards the PRACK request to I-CSCF2a. 

Table 17.5.2-85: PRACK (I-CSCFlb to l-CSCF2a) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscfl. homel. net ;branch=z9hG4bK332b2 3. 1, SIP/ 2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:scscf2. home 2 .net; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) (3home2 .net; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 



86. PRACK (I-CSCF2a to S-CSCF2) - see example in table 17.5.2-86 
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I-CSCF2a forwards the PRACK request to S-CSCF2. 

Table 17.5.2-86: PRACK (l-CSCF2a to S-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 

Route: sip: scscf2 .home2 . net; Ir, sip: icscf2_p.home2 . net; Ir, sip:pcscf2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

87. PRACK (S-CSCF2 to I-CSCF2b) - see example in table 17.5.2-87 

S-CSCF2 forwards the PRACK request to I-CSCF2b. 

Table 17.5.2-87: PRACK (S-CSCF2 to l-CSCF2b) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1) @homel . net ; tokenized-by=homel . net , SIP/ 2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 64 

Route: sip: icscf 2_p.home2 . net; Ir, sip:pcscf 2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

88. PRACK (I-CSCF2b to P-CSCF2) - see example in table 17.5.2-88 

I-CSCFlb forwards the PRACK request to P-CSCF2. 

Table 17.5.2-88: PRACK (l-CSCF2b to P-CSCF2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_p.home2 . net; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net; tokenized-by=home2 . net, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 63 

Route : sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 
Rack: 
Content-Length : 

89. PRACK (P-CSCF2 to UE2) - see example in table 17.5.2-89 

P-CSCF2 and forwards the PRACK request to the UE2. 
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Table 17.5.2-89: PRACK (P-CSCF2 to UE2) 

PRACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 . visited2 . net;branch=z9hG4bK361k21 . 1 

Max-Forwards : 62 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 

90. 200 OK (UE2 to P-CSCF2) - see example in table 17.5.2-90 

UE2 acknowledges the PRACK request with a 200 OK response. 

Table 17.5.2-90: 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 135 PRACK 

Content-Length: 

91. 200 OK (P-CSCF2 to I-CSCF2b) - see example in table 17.5.2-91 

P-CSCF2 forwards the 200 OK response to I-CSCF2b. 

Table 17.5.2-91 : 200 OK (P-CSCF2 to l-CSCF2b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2„p . home2 . net ;branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net ; tokenized-by=home2 . net , SIP/ 2. 0/UDP 
icscfl_s. home 1. net ;branch=z9hG4bK312a32. 1, SIP/2. 0/UDP token (SIP /2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

92. 200 OK (I-CSCF2b to S-CSCF2) - see example in table 17.5.2-92 

I-CSCF2b forwards the 200 OK response to S-CSCF2. 

Table 17.5.2-92: 200 OK (l-CSCF2b to S-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1, SIP/2. 0/UDP icscf l_s . home 1 . net ; branch=z9hG4bK3 12a3 2 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf l.visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

93. 200 OK (S-CSCF2 to I-CSCF2a) - see example in table 17,5.2-93 
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S-CSCF2 forwards the 200 OK response to I-CSCF2a. 

Table 17.5.2-93: 200 OK (S-CSCF2 to l-CSCF2a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

94. 200 OK (I-CSCF2a to I-CSCFlb) - see example in table 17.5.2-94 

I-CSCF2a forwards the 200 OK response to I-CSCFlb. 

Table 17.5.2-94: 200 OK (l-CSCF2a to I-CSCFlb) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s .homel . net; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

95. 200 OK (I-CSCFlb to S-CSCFl) - see example in table 17.5.2-95 

S-CSCF forwards the 200 OK response to S-CSCFl. 

Table 17.5.2-95: 200 OK (I-CSCFlb to S-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

96. 200 OK (S-CSCFl to I-CSCFla) - see example in table 17.5.2-96 

S-CSCFl forwards the 200 OK response to I-CSCFla. 

Table 17.5.2-96: 200 OK (S-CSCFl to I-CSCFla) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK24 Of 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

97. 200 OK (I-CSCFla to P-CSCFl) - see example in table 17.5.2-97 
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I-CSCFl forwards the 200 OK response to P-CSCFl. 

Table 17.5.2-97: 200 OK (I-CSCFl a to P-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 

98. 200 OK (P-CSCFl to UEl) - see example in table 17.5.2-98 

P-CSCFl forwards the 200 OK response to the originator. 

Table 17.5.2-98: 200 OK (P-CSCFl to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 

99. 200 OK (UE2 to P-CSCF2) - see example in table 17.5.2-99 

UE acknowledges the Invite request with a 200 OK response. 

Table 17.5.2-99: 200 OK (UE2 to P-CSCF2) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: 

To: 

Call-ID: 

CSeq: 132 INVITE 

Contact: sip: [5555: : eee : f f f : aaa:bbb] 

Content-length: 

100. Approval of QoS Commet 

P-CSCF2 approves the commitment of the QoS resources for this additional media. 

101. UE2 can start the new media 

102. 200 OK (P-CSCF2 to I-CSCF2b) - see example in table 17.5.2-102 

P-CSCF2 forwards the 200 OK response to I-CSCF2b. 

Table 17.5.2-102: 200 OK (P-CSCF2 to l-CSCF2b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_p.home2 . net; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net; tokenized-by=home2 . net, S IP /2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/2. 0/UDP 
scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : icid-value=1234bcd987 6e; icid-generated-at= [5555: :f5f:e4e:d3d:c2c] ; 
ggsn=[5555: :d6d:c7c:b8b:a9a] ; pdp-sig=no; gcid=309685742; auth-token=86243614; flow-id=l 
From: 
To: 
Call-ID: 
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CSeq: 
Contact : 

Content -length: 



103. 200 OK (I-CSCF2b to S-CSCF2) - see example in table 17.5.2-103 

I-CSCF2b forwards the 200 OK response to S-CSCF2. 



Table 17.5.2-103: 200 OK (l-CSCF2b to S-CSCF2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-length : 

104. 200 OK (S-CSCF2 to I-CSCF2a) - see example in table 17.5.2-104 

S-CSCF2 forwards the 200 OK response to I-CSCF2a. 

Table 17.5.2-104: 200 OK (S-CSCF2 to l-CSCF2a) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/ 2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc: ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content -length: 

105. 200 OK (I-CSCF2a to I-CSCFlb) - see example in table 17.5.2-105 

S-CSCF forwards the 200 OK response to I-CSCFlb. 

Table 17.5.2-105: 200 OK (l-CSCF2a to I-CSCFlb) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content -length: 



106. 200 OK (I-CSCFlb to S-CSCFl) - see example in table 17.5.2-106 

I-CSCFlb forwards the 200 OK response to S-CSCFl. 
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Table 17.5.2-106: 200 OK (l-CSCF2a to l-CSCF1b) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Contact : 

Content-length : 

107. 200 OK (S-CSCFl to I-CSCFla) - see example in table 17.5.2-107 

S-CSCFl forwards the 200 OK response to I-CSCFla. 

Table 17.5.2-107: 200 OK (S-CSCFl to I-CSCFla) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content -length: 

108. 200 OK (I-CSCFla to P-CSCFl) - see example in table 17.5.2-108 

I-CSCFla forwards the 200 OK response to P-CSCFl. 

Table 17.5.2-108: 200 OK (I-CSCFla to P-CSCFl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-length : 

109. Approval of QoS Commit 

P-CSCFl approves the commitment of the QoS resources for this additional media. 

1 10. 200 OK (P-CSCFl to UEl) - see example in table 17.5.2-110 

S-CSCF forwards the 200 OK response to UEl. 

Table 17.5.2-110: 200 OK (P-CSCFl to UEl) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content -length: 

HI. UEl can start new media 

1 12. ACK (UEl to P-CSCFl) - see example in table 17.5.2-112 
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UEl responds to the final response with a SIP ACK request, which is passed to the destination via the 
signalhng path. The request is sent first to P-CSCFl. 

Table 17.5.2-112: ACK (UEl to P-CSCFl) 

ACK sip: [5555: :eee:fff :aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: sip : userl_publicl@homel . net ; tag=171828 

To: sip:user2_publicl@home2 . net; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 132 ACK 

Content-Length: 

113. ACK (P-CSCFl to I-CSCFla) - see example in table 17.5.2-113 

Table 17.5.2-113: ACK (P-CSCFl to l-CSCF1a) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : sip : icscf l_p . homel .net;lr, sip:token(sip:scscfl. homel .net; Ir, 

sip : icscf l„s . homel .net; Ir ) @ homel .net; tokenized-by=homel .net, sip : icscf 2_s . home 2 .net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Content-length: 

1 14. ACK (I-CSCFla to S-CSCFl) - see example in table 17.5,2-114 

Table 17.5.2-114: ACK (I-CSCFla to S-CSCFl) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: sip: scscfl .homel . net; Ir, sip: icscf l_s .homel . net; Ir, sip: icscf 2_s .home2 . net; Ir, 
sip:token (sip: scscf2 . home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, 
sip:pcscf2 .visited2 . net; Ir 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

1 15. ACK (S-CSCFl to I-CSCFlb) - see example in table 17.5,2-115 

Table 17.5.2-115: ACK (S-CSCFl to l-CSCF1b) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK24 Of 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : sip : icscf l_s . homel .net;lr, sip: icscf 2__s . home 2 .net;lr, sip:token(sip:scscf2. home 2 . net ; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) (3home2 .net; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 
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1 16. ACK (I-CSCFlb to I-CSCF2a) - see example in table 17.5.2-116 

Table 17.5.2-116: ACK (l-CSCF1b to l-CSCF2a) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : sip : icscf 2_s . home 2 .net;lr, sip:token(sip:scscf2. home 2 . net ; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

1 17. ACK (I-CSCF2a to S-CSCF2) - see example in table 17.5.2-117 

Table 17.5.2-117: ACK (l-CSCF2a to S-CSCF2) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_.s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP token (SIP/ 2. 0/UDP 
scscfl .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 65 

Route: sip: scscf 2 .home2 . net; Ir, sip: icscf 2_p.home2 . net; Ir, sip:pcscf 2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

118. ACK (S-CSCF2 to I-CSCF2b) - see example in table 17.5.2-118 

Table 17.5.2-118: ACK (S-CSCF2 to l-CSCF2b) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1) @homel . net ; tokenized-by=homel . net , SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 64 

Route: sip: icscf 2_p.home2 . net; Ir, sip:pcscf 2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 

1 19. ACK (I-CSCF2b to P-CSCF2) - see example in table 17.5.2-119 

Table 17.5.2-119: ACK (S-CSCF2 to l-CSCF2b) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_p . home2 . net ; branch=z9hG4bK556u87 . 1, SIP/2. 0/UDP token (SIP/2 . 0/UDP 
scscf2.home2.net;branch=z9hG4bK7 64z87. 1, SIP/2. 0/UDP 

icscf 2_s.home2. net ;branch=z9hG4bK871y 12. 1) @home2 . net; tokenized-by=home2 . net, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP token (SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 63 
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Route : sip:pcscf 2 . visited2 . net; Ir 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



120. ACK (P-CSCF2 to UE2) - see example in table 17.5.2-120 

Table 17.5.2-120: ACK (P-CSCF2 to UE2) 

ACK sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 



17.6 Error handling: Session Initiation (not provided) 

An example of this flow is not shown in the present document. 



18 Signalling flows for session release (hiding) 



18.1 Introduction 



See subclause 8.1. 



18.2 Mobile terminal initiated session release 

Figure 18.2-1 shows a mobile terminal initiated IM CN subsystem application (SIP) session release. It is assumed that 
the session is active and that the bearer was established directly between the two visited networks (the visited networks 
could be the home network in either or both cases). 

NOTE 1: For the puposes of the description of the I-CSCF in figure 18.2-1 and in the associated text, it is assumed 
that the party that established the session initiated the clearing. For clearing in the reverse direction, there 
is a slight change in the optionality of the 1-CSCFs between the S-CSCFs. This is as described for session 
establishment. 
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Figure 18.2-1: Mobile initiated session release 
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1. SIP BYE (UE to P-CSCF) - see example in table 18.2-1 

One mobile party hangs up, which generates a SIP BYE request from the UE to the P-CSCF. 

Table 18.2-1 : SIP BYE (UE to P-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards: 70 

From: sip : userl_publicl@homel .net 

To : sip: user 2_publicl@home2 . net; tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq: 153 BYE 

Content-Length: 

Request-URI: takes the value of the Contact header of the original received response. 

Via: takes the value of either the IP address or the FQDN of the originating UE. 

From:/To:/Call-ID: the example contents of the From header, the To header and Call-ID header are used to identify 
the session being cleared, and therefore are identical to those of the previously received response 
for that session, so that they include any tag parameters. 

CSeq: the content of the Cseq header must have a higher sequence number than the previous transaction. 

Here it is assumed that a Cseq value no greater than 152 has been previously used. 

2. Release PDF 

Steps 2 and 3 may take place before or after Step 1 and in parallel with Step 4. The UE initiates the release 
of the bearer PDP context. The GPRS subsystem releases the PDP context. The IP network resources that had 
were reserved for the message receive path to the mobile for this session are now released. This is initiated 
from the GGSN. If RS VP was used to allocated resources, then the appropriate release messages for that 
protocol would invoked here. 

3. Rls. Response 

The GPRS subsystem responds to the UE. 

4. Remove resource reservation 

The P-CSCF removes the authorization for resources that had previously been issued for this endpoint for 
this session. This step will also result in a release indication to the GPRS subsystem to confirm that the IP 
bearers associated with the session have been deleted. 

5. SIP BYE (P-CSCF to I-CSCF) - see example in table 18.2-5 

The P-CSCF sends a SIP BYE request to the I-CSCF (THIG) hiding the S-CSCF of the releasing party. 

Table 18.2-5: SIP BYE (P-CSCF to I-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : sip : icscf l_p . homel .net;lr, sip:Token(sip: scscf l_s . homel . net ; Ir ) @homel .net;tokenized- 
by=homel . net ) @ homel .net; tokenised-by=home2 .net, sip : icscf 2_s . home 2 .net;lr, sip: 
Token (sip: scscf2 . home 2 . net ; Ir, sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, 
sip: @pcscf2 .visited2 . net; Ir 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

6. SIP BYE (I-CSCF to S-CSCF) - see example in table 18.2-6 

The I-CSCF (THIG) sends a SIP BYE request to the S-CSCF of the releasing party. 
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Table 18.2-6: SIP BYE (l-CSCF to S-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_p . homel . net ; branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa:bbb: ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route: sip: scscfl .homel . net; Ir, sip: icscf l_s .homel . net; Ir, sip: Token (sip: scscf 2 .home2 . net; Ir, 
sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=home2 .net, sip:@pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

7. SIP BYE (S-CSCF to I-CSCF) - see example in table 18.2-7 

The SIP BYE request is sent from the S-CSCF to the I-CSCF (THIG). 

Table 18.2-7: SIP BYE (S-CSCF to I-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, SIP/ 2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : sip : icscf l_s . homel .net;lr, sip: icscf 2_s . home 2 .net;lr, sip:Token(sip:scscf2. home 2 .net; Ir, 

sip : icscf 2_p . home 2 .net; Ir ) @ home 2 .net; tokenized-by=homel .net, sip:pcscf2.visited2.net;lr 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

8. SIP BYE (I-CSCF to I-CSCF) - see example in table 18.2-8 

The SIP BYE request is sent from the I-CSCF (THIG) to the I-CSCF of the network of the other party. 

Table 18.2-8: SIP BYE (I-CSCF to I-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf l_s . homel . net ;branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards: 66 

Route : sip:Token(sip:scscf2. home 2 .net;lr, sip: icscf 2_p . home 2 .net; Ir ) (3 home 2 .net;tokenized- 
by=home2 .net, sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

9. SIP BYE (I-CSCF to S-CSCF) - see example in table 18.2-9 

The SIP BYE request is forwarded from the I-CSCF that was used to determine the location of S-CSCF of 
the other party. 

Table 18.2-9: SIP BYE (I-CSCF to S-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/ 2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP icscf l_p.homel . net; branch=z9hG4bK351g4 5 . 1, 
SIP/2. 0/UDP pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa: bbb: ccc : ddd] ; branch=z9hG4bKnashds7) Shomel . net; tokenized-by=homel . net 
Max-Forwards : 65 

Route: sip: scscf2 .home2 . net; Ir, sip: icscf2_p.home2 . net; Ir, sip:pcscf2 . visited2 . net; Ir 
From: 
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To: 

Call-ID: 

CSeq: 

Content-Length: 

10. SIP BYE (S-CSCF to I-CSCF) - see example in table 18.2-10 

The SIP BYE request is forwarded to a I-CSCF (THIG). 

Table 18.2-10: SIP BYE (S-CSCF to I-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2. 1, SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 64 

Route: sip: icscf 2_p.home2 . net; Ir, sip:pcscf 2 . visited2 . net; Ir 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

1 1. SIP BYE (I-CSCF to P-CSCF) - see example in table 18.2-11 

The I-CSCF (THIG) forwards the SIP BYE request to the P-CSCF. 

Table 18.2-11: SIP BYE (I-CSCF to P-CSCF) 

BYE sip: [5555: :eee:fff:aaa:bbbl SIP/2.0 

Via: SIP/2. 0/UDP icscf2_p.home2.net, SIP/2. 0/UDP Token (scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, 
SIP/ 2 .0/UDP icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 . 1) @home2 . net ; tokenized-by=home2 . net, SIP/2 . 0/UDP 
icscfl_s.homel.net;branch=z9hG4bK312a32. 1, SIP/ 2. 0/UDP Token (SIP/2. 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net ; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
Max-Forwards : 63 

Route : sip:pcscf2.visited2.net;lr 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

12. Remove resource reservation 

The P-CSCF removes the authorisation for resources that had previously been issued for this endpoint for this 
session. This step also results in a release indication to the GPRS subsystem to confirm that the IP bearers 
associated with the UE#2 session have been deleted. 

13. SIP BYE (P-CSCF to UE) - see example in table 18.2-13 

The P-CSCF forwards the SIP BYE request on to the UE. 

Table 18.2-13: SIP BYE (P-CSCF to UE) 

BYE sip: [5555: :eee:fff:aaa:bbb] SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK361k21 . 1 

Max-Forwards : 62 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



14. 200 OK (UE to P-CSCF) - see example in table 18.2-14 
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The mobile responds with a 200 OK response, which is sent back to the P-CSCF. 

Table 18.2-14: 200 OK (UE to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK361k21 . 1 

From; 

To: 

Call-ID: 

CSeq: 

Content-Length: 

15. Release PDF 

Steps 15 and 16 may be done in parallel with step 14. The Mobile initiates the release of the bearer PDP 
context. 

16. Rls response 

The GPRS subsystem releases the PDP context. The IP network resources that had were reserved for the 
message receive path to the mobile for this session are now released. This is initiated from the GGSN. If 
RSVP was used to allocated resources, then the appropriate release messages for that protocol would invoked 
here. 

17. 200 OK (P-CSCF to I-CSCF) - see example in table 18.2-17 

The P-CSCF sends a 200 OK response to the I-CSCF (THIG). 

Table 18.2-17: 200 OK (P-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_p.home2.net, SIP/2. 0/UDP Token (scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, 
SIP/ 2. 0/UDP icscf2_s.home2.net;branch=z9hG4bK871yl2. 1) @home2 . net ; tokenized-by=home2 . net , SIP/ 2. 0/UDP 
icscfl_s. home 1. net ;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

icscf l_p.homel . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf l.visitedl. net ;branch=z9hG4bK240f 34. 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

18. 200 OK (I-CSCF to S-CSCF) - see example in table 18.2-18 

The I-CSCF (THIG) sends a 200 OK response to the S-CSCF. 

Table 18.2-18: 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP icscf l_s . home 1 . net ;branch=z9hG4bK312a32 . 1, 
SIP/2. 0/UDP Token (SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

19. 200 OK (S-CSCF to I-CSCF) - see example in table 18.2-19 

The S-CSCF of the other party forwards the 200 OK response to its selecting I-CSCF. 
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Table 18.2-19: 200 OK (S-CSCF to l-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
icscfl_s. home 1. net ;branch=z9hG4bK312a32. 1, S IP /2. 0/UDP Token (SIP/ 2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

icscf l_p. home 1 . net; branch=z9hG4bK351g4 5 . 1) ghomel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 ; : aaa ; bbb : ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

20. 200 OK (I-CSCF to I-CSCF) - see example in table 18.2-20 

The selecting I-CSCF forwards the 200 OK response to the I-CSCF (THIG). 

Table 18.2-20: 200 OK (I-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; branch=z9hG4bK312a32 . 1, SIP/2. 0/UDP Token (SIP/2 . 0/UDP 
scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf l_p. homel . net; branch=z9hG4bK351g4 5 . 1) @homel . net; tokenized-by=homel .net, SIP/2 . 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

21. 200 OK (I-CSCF to S-CSCF) - see example in table 18.2-21 

The I-CSCF (THIG) forwards the 200 OK response to the S-CSCF. 

Table 18.2-21 : 200 OK (I-CSCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscfl_p.homel.net;branch=z9hG4bK351g4 5. 1, S IP /2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK24 Of 34 . 1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

22. 200 OK (S-CSCF to I-CSCF) - see example in table 18.2-22 

The S-CSCF of the releasing party forwards the 200 OK response to the I-CSCF (THIG). 

Table 18.2-22: 200 OK (S-CSCF to I-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 

23. 200 OK (I-CSCF to P-CSCF) - see example in table 18.2-23 

The I-CSCF (THIG) forwards the 200 OK response to the P-CSCF of the releasing party. 



£75/ 



3GPP TS 24.228 version 5.3.0 Release 5 695 ETSI TS 1 24 228 V5.3.0 (2002-1 2) 

Table 18.2-23: 200 OK (l-CSCF to P-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc ; ddd] ; branch=z9hG4bKnashds7 
From; 
To: 

Call-ID: 
CSeq: 
Content-Length: 

24. SIP OK (P-CSCF to UE) - see example in table 18.2-24 

The P-CSCF of the releasing party forwards the 200 OK response to the UE. 
Table 18.2-24: SIP 200 OK (P-CSCF to UE) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 

18.3 PSTN initiated session release (not provided) 

An example of this flow is not shown in the present document. 

18.4 Error handling: session release (not provided) 

An example of this flow is not shown in the present document. 

19 Network initiated procedures (hiding) (not provided) 

An example of this flow is not shown in the present document. 

20 Procedures to enable enhanced multimedia services 
(hiding) (not provided) 

An example of this procedure is not shown in the present document. 
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